CPack Packaging for Windows/Mac (and possibly Linux)

[Pau Garcia i Quiles]

Quoting Alexander Neundorf <neundorf at kde.org>:

> On Sunday 24 August 2008, Pau Garcia i Quiles wrote:
>> Quoting Sune Vuorela <debian at pusling.com>:
>> > 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 <sourcepkg>_<upstreamversion>.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)