From kde-buildsystem Sat Sep 06 00:13:16 2008 From: Pau Garcia i Quiles Date: Sat, 06 Sep 2008 00:13:16 +0000 To: kde-buildsystem Subject: Re: CPack Packaging for Windows/Mac (and possibly Linux) Message-Id: <20080906021316.pdsbte4l0cc0g8w0 () www ! elpauer ! org> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=122066002819299 Quoting Alexander Neundorf : > On Sunday 24 August 2008, Pau Garcia i Quiles wrote: >> Quoting Sune Vuorela : >> > On Sunday 24 August 2008 23:25:03 Mike Arthur wrote: >> >> In my experience using CPack however I'm pretty sure we could get the >> >> package generators in such a state that they could be used downstream. >> > >> > My impression (without much look at it) is that the deb support might be >> > producing technically valid debian packages, but not of a quality >> > suitable for debian. >> > >> > .. and some guy within the last months came by debian developer maillist >> > talking about how he implemented the .deb support - and a few mails >> > later he said that he never read the debian packaging policies, but just >> > reverse engineered .deb packages. >> > >> > That has at least convinced me to not spend any further time looking at >> > the .deb support in cmake in the near future. >> >> The main problem I see with .deb packages produced by CPack is they >> are not usable by autobuilders: CPack only produces binary packages, >> not source packages (.orig.tar.gz + .diff.gz + .dsc). > > I think the part with the .diff.gz just doesn't match what cpack is supposed > to do. > There is a project foo (with a cmake buildsystem) developped by Bob. > Bob wants > to create packages for foo. So he adds the cpack logic to his build files. > Now he can create source packages and binary packages (let's start simple > with .tar.gz). Two different things here: A) Native vs non-native package B) Why the "debian" directory should not be in upstream The answers are not in the Debian Policy Manual but they are in the Debian Mentors FAQ ( http://newpeople.debian.org/~mpalmer/debian-mentors_FAQ.html ) A) What is the difference between a native Debian package and a non-native package? (From Matthijs Mohlmann, with additions by Thijs Kinkhorst) 1. Non-Native Debian Package A non-native debian source package contains a dsc, diff.gz and an orig.tar.gz file. The version for a non-native Debian package looks like UpstreamVersion-DebianVersion for example: 2.8-1. In the diff.gz: These are the modifications you made to the package. It contains the debian directory and the modifications you made to the source tree, if any. In the orig.tar.gz: This is the upstream tarball. You should very rarely make changes to this file, and you should never ever make changes unless you explicitly understand why you are making them. All changes should normally go into the diff.gz. 2. Native Debian Package The Version number for a debian native package is only the version, it doesn't have a Debian revision number, it looks like: 2.8. A native package contains only a dsc and a tar.gz file. The disadvantage of a native package is that there is no clear separation between "upstream code" and "Debian changes". This means that it is harder to separate out patches that should be sent upstream, and unnecessarily muddies the waters of who is responsible for what. Additionally, a native package requires a whole new .tar.gz to be created whenever there are packaging changes (which wastes bandwidth and mirror space), while a non-native package only requires the upload of a new .diff.gz, which is typically much smaller. Native debian packages are often accidentally built when upstream tarball (.orig.tar.gz) is named incorrectly. It should always be named _.orig.tar.gz. 3. When to use a native vs a non-native debian package You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. A few examples of normal packages are: libc6, apache, phpmyadmin. But linda, lintian, dpkg and some other tools are purely developed for debian, and make no sense being released in another distribution. > So the logic for the packaging has been added by the original > developer of the > project. The original developer by definition has no diff against the > original version, because he creates the original version. 2) What's wrong with upstream shipping a debian/ directory? There are cases where upstream ships a tarball which already contains a debian directory. This is undesirable, even if you're upstream yourself or can commit there. Keep the released tarballs (used as .orig.tar.gz) and the debian directory separated. The problem is that at some point, upstream's debian directory will deviate from the one in the Debian package -- because the maintainer changes, the directory was already outdated, or someone does an NMU or a security upload. Because it was The .diff.gz will now be a diff between the two debian dirs, which is very confusing. The Debian package format is designed to keep upstream and Debian-specific neatly separated into orig.tar.gz and .diff.gz. Putting the debian dir in the .orig.tar.gz confuses this. If upstream has a debian directory in their releases, you should contact them and ask if they can remove the debian/ directory from their tarball releases. There's no need to remove the debian directory from their revision control system (although if it's out of date they may decide to do so anyway), but at the very least the directory shouldn't appear in releases. If you are upstream yourself, well, you can ask yourself to do it. > For the dsc file, it shouldn't be hard to add support for that to cpack. > How should support for a diff.gz look like ? It's not the .dsc file but the control files, the rules file, the .install files, etc. Take a look at the Debian Policy Manual ( http://www.debian.org/doc/debian-policy/index.html ), specially sections 4 (rules) and 5 (control). How would I add support for source packages, i. e. creation of .orig.tar.gz, .diff.gz and .dsc files: 1) When building the source packages, CMake would create a temporary directory with the project sources and package this as the .orig.tar.gz file. This directory should abide by the naming rules stated in the Debian Policy Manual. 2) Now, create a "debian" directory in the temporary directory and using the CPack Debian generator, create the rules file, control file, changelog, .install files, docs file, etc. 3) Now you can run "dpkg-buildpackage" and "debsign" (or "debuild") in the temporary directory and it will use the .orig.tar.gz generated in step 1 to create the .diff.gz and the .dsc files. Of course this would only work on Linux (probably only on Debian-derived distributions), so adding to CPack support for what dpkg-buildpackage and debsing do would be even better. Don't take me wrong: I love CMake and CPack and even binary-only support for .deb is extremely useful, but I can't get enough candy :-) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem