[CMake] CPack DEB Packaging: Automate dependency resolution

Eric Noulard eric.noulard at gmail.com
Wed Nov 5 03:06:00 EST 2008


2008/11/5 Mathieu Malaterre <mathieu.malaterre at gmail.com>:
> 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:
>>> > 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/...

In fact I would temper that.
If you want to build

- RPM then you should use rpm building tools
    http://linuxhacks.org/tutorials/jakes_rpm_build_tutorial.php
- NSIS then you should use NSIS building tools
    http://nsis.sourceforge.net/Main_Page
- ZIP ....
- DPKG ...

trying to fake the "usual" tool may at best lead to a unusable package.

HOWEVER, I do think you may try to use RPM on a debian box
as soon as you may install RPM tools on Debian,
see e.g.: http://packages.debian.org/etch/rpm

I you cannot then build whatever you can and use alien
http://kitenet.net/~joey/code/alien/.

>> 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.

I agree with that, the added value here is that even if the CPack generated
package is not 100% debian approved you may install it using dpkg
and UNINSTALL it too, this is far better than doing mostly manual "uninstall".

>> 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.

May be CMake/CPack may work WITH dpkg tools an not as a replacement.
That is cpack DEB generator may call the appropriate
dpkg-
dh_XXXX
etc...

I may be wrong since I did not try to build a deb package myself.

>> 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.

And what do you think of being able to use an external debian/ directory
with something like:

cpack -D CPACK_DEB_DEBIAN_DIRECTORY=/path/to/debian -G DEB

then the debian package may maintain it's own debian dir by hand (as usual)
http://www.debian.org/doc/manuals/maint-guide/index.en.html
and use cpack to package the DEB (either source or binary).

/path/to/debian may be stored in the source tree if the debian packager
is a debian maintainer.

>> 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).

unless you accept to take into account "out-of-tree" patch

cpack -D CPACK_DEB_DEBIAN_PATCHES=/path/to/diff.gz -G DEB

> 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. ).

Agreed, but
CMake may help to export already [CMake] specified dependencies

cmake --export-src-dependencies

may be in some xml output, that could be processed using
xlst in order to produce initial src dependencies to be copy/paste
by debian maintainer.

I don't really know CMake internal regarding dependencies but the
informations must exists somewhere in order to be able to generate
makefile.

> - 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.

In the same way, if CMake do provide some export facilities
regarding the content of "install" rules then the duplication would be easier.

cmake --export-install-command

and I know that the export may be partial since we have the nice:
install(SCRIPT ...)
install(CODE ...)

> 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 ?

I'm not sure to understand what you mean here.

> 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

Yes that pretty much what I meant by

cmake --export-install-command

with a missing --component= arg.


-- 
Erk


More information about the CMake mailing list