CPack Packaging for Windows/Mac (and possibly Linux)

[Andreas Pakulat]

On 05.09.08 21:33:09, Alexander Neundorf wrote:
> 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).
> 
> 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. 
> 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 ?

IMHO the needs of a software developer wanting to provide source and
binary packages and the needs of a distribution wanting to do the same
are different enough to accept the fact that each needs its own way of
doing the packaging.

The upstream author that wants to have packages for major platforms,
simply wants a fast and easy way to put the result of a make install
into a binary package for a distribution. Without having to know
in-depth how that distribution handles certain things.

OTOH distribution packagers want to adjust the sources to better
integrate into their distribution (patches), they want to provide
security about the safety of the packages (signing) and they want to
easily build binary packages for a dozen architectures from a single
source package (including their changes). They might also want to split
the application/library into multiple packages.

So IMHO it simply doesn't make sense to use CPack for distribution
packages.

Andreas

-- 
A visit to a strange place will bring fresh work.