[CMake] CPack DEB Packaging: Automate dependency resolution

[Mathieu Malaterre]

On Tue, Nov 4, 2008 at 8:16 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Tuesday 04 November 2008, Mathieu Malaterre wrote:
>> On Tue, Nov 4, 2008 at 12:43 PM, Mike Arthur <mike at mikearthur.co.uk> wrote:
>> > On Tuesday 04 November 2008 11:36:12 David Graf wrote:
>> >>  How exactly to you use dpkg-shlibdeps? Because I get the following bug:
>> >> dpkg-shlibdeps: failure: cannot read debian/control: No such file or
>> >> directory
>> >
>> > You really should be using Debian utilities.
>>
>> Not unless you are on a debian machine. Technically nothing should
>> prevent your from creating a deb package on redhat/slackware/...
>
> Yes.
> Maybe we need to separate between debian packages intended for inclusion in
> debian, and debian packages created by 3rd parties intended to be distributed
> just for their app, without immediate goal of being included in debian.
> The first case, then you probably want to use the debian packaging tools,
> because you have to follow all guidelines. Then you probably also have (?) to
> create debian source packages. I think creating debian source packages with
> cmake doesn't make sense.
> http://www.infodrom.org/Debian/doc/maint/Maintenance-pkgbuild.html
> A debian source package consists of the source archive, the debian patches and
> a metadata file.
> So what should a debian source package generator generate ?
> The orig.tar.gz is no problem, cmake does that.
> The metadata file is just a text file which accompanies the tar file and can
> just be written by the packager, I don't see what cmake should do there.
>
> The diff.gz file would always be empty. Since the debian source package for a
> cmake package would be created directly from the sources, it could never
> include a patch (since this is always an add-on to the sources, but the
> source package would be created by the sources, which just doesn't have any
> patches against itself).
> Am I wrong with this ?

Indeed cmake would be of limited help here. But as I said there some
painful steps in writing debian specific files:
- explicit listing of src dependencie, this is a trial and error step
AFAIK, while this is *completely* automated using cmake, this also
means that depending on build option src deb may be varying (which is
something DD don't care about, but is pretty cool anyway. ).
- when I spent time designing the layout of the installation, I
certainly do not want to waste  time, in writing a duplicate(*) file
that exactly list how the package should looks like. Eg. typical
package are split in 'libs', 'tools', 'dev','python-libs' ...
Of course cmake leaves me with a little too mcuh flexibility but it is
currently a pain to maintain the installation layout in both cmake and
the equivalent debian/* files.

So my initial re-write of the deb packager was to generate the
separation of group of pakage.

To illustrate; here is an example:

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/debian/libgdcm2-dev.install?revision=4449&view=markup

This exactly match what cpack sees as "development" group package...

Make sense ?

-- 
Mathieu
(*) and by duplicate I really mean it. Look for example at the vtk
package, which has been consistently broken because the debian
installation would not install required stuff, it would have been
fantastic to simply ask cpack for the list of file needed for a
particular package group:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486794