Hi there,

Because of the recent feedback I got in building debian package
using cmake, I decided to rewrite the current -broken- support.

As far as I understand :
1. dpkg-buildpackage *has* to be the entry point (nothing else, not
even 'cmake')

2. dpkg-buildpackage requires a 'debian' subdirectory to be present in
the source directory directly (it cannot be outside of the project
first level subdirectory).

3. I was suggested libopensync for cmake/debian package start.
3.1 where is the internal name 'libopensync1exp3' coming from ? what
does the '1exp3' stand for ?
3.2 In opensync/debian/control file, where does the 'Build-Depends'
comes from ? Is this computed by some tool or is this purely
human-based ?

4. Let say my package is named 'foo',
4.1 the 'libfoo' package is assumed to provide the runtime libraries
4.2 the 'libfoo-dev' package is assumed to provide the shared lib
symlinks + headers file
4.3 I could not find any naming convention consistant for 'utils' or
'tools', basically applications (main function) based on 'libfoo'.

I am sure there will be tiny differences that will prevent cmake from
generating complete 'control' files (for instance, Conflicts section
cannot be generated by a machine), I am targetting at getting 95% of
the job done and hopefully 100% for simple project. Which will means
that installation will be (automatically) consistant in between a
Linux-debian/MacOSX-darwin/Win32-windows machine.

For references:

* http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
and
* http://gdcm.svn.sourceforge.net/viewvc/gdcm/branches/gdcm-2-0/debian/

Regards,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jun 23, 2008 at 07:04:09PM +0200, Mathieu Malaterre wrote:
> 3. I was suggested libopensync for cmake/debian package start.

I suggested it as a package which builds for different python versions.
By that time, I didn't realize you were doing something like
deb-creation support in cmake.

In sofar, I don't think libopensync might be the best example to learn
basic Debian packaging.

> 3.1 where is the internal name 'libopensync1exp3' coming from ?

It's set in opensync/CMakeLists.txt (in the Debian source package, not
in the upstream code).

> what does the '1exp3' stand for ?

It's the library version.

> 3.2 In opensync/debian/control file, where does the 'Build-Depends'
> comes from ? Is this computed by some tool or is this purely
> human-based ?

This is human based.


Michael


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Mathieu Malaterre" <mathieu.malaterre@gmail.com> wrote:

> 3. I was suggested libopensync for cmake/debian package start.
> 3.1 where is the internal name 'libopensync1exp3' coming from ? what
> does the '1exp3' stand for ?

You shouldn't try to invent a new system for building packages if you
are not familiar enough with Debian Policy to know that yourself.

Sorry, but that's how it is.

Regards, Frank
--
Frank Küster
Debian Developer (teTeX/TeXLive)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jun 23, 2008 at 9:57 PM, Frank Küster <frank@debian.org> wrote:
> "Mathieu Malaterre" <mathieu.malaterre@gmail.com> wrote:
>
>> 3. I was suggested libopensync for cmake/debian package start.
>> 3.1 where is the internal name 'libopensync1exp3' coming from ? what
>> does the '1exp3' stand for ?
>
> You shouldn't try to invent a new system for building packages if you
> are not familiar enough with Debian Policy to know that yourself.
>
> Sorry, but that's how it is.

Hi Frank,

That's just rude. Even if you are a super star in the debian-world
and a fantastic hacker, your comment can not possibly be coming from a
grown up adult.
You did NOT even try to make a tiniest effort to understand what I
am doing here. I am NOT reinventing the wheel here. As I said in the
very first line of my email, I understood my previous mistake in the
early implementation of debian package. That's why I am doing it the
'right' way (as I have been suggested in the previous thread in this
very same mailing list).
The output of cmake will be a bunch of files: control,
libfoo.install, so that you can run dpkg-buildpackage as any other
debian package.

Why am I doing that ? Because *this is reinventing the wheel* when
you use cmake and duplicate code in *.install file instead of simply
asking cmake to generate those file for you. If you had read the wiki
page I send, all the information is in the cmakelists, just not
available as regular debian package files.
The other goal is to also export cmake dependencies (cmake is doing
system inspection), so that one should not have to write the
'Build-Depends' line. cmake knows what is needs to compile, so indeed
this line is purely machine generated.

As I said, I understand that some info (Conflicts typically) will be
human generated, but I am sure that 95% of writing control/*.install
file can be automatically generated by the build system: cmake in my
case. As far as I understand generating those debian files can be
tedious and error prone, plus it duplicate the logic in cmake anyway.
This should remove most of the boiler plate code, when a project is
using cmake.



--
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le lundi 23 juin 2008 Ã* 22:11 +0200, Mathieu Malaterre a écrit :
> That's just rude. Even if you are a super star in the debian-world
> and a fantastic hacker, your comment can not possibly be coming from a
> grown up adult.

Rude? Come on. You are trying to reinvent the wheel in the worst
possible way, without understanding what a wheel is for and without
obviously reading the documents that explain what are wheels and how to
make them (Debian Policy and New Maintainer’s guide). Starting from
that, Frank could have been much more rude.

> You did NOT even try to make a tiniest effort to understand what I
> am doing here. I am NOT reinventing the wheel here. As I said in the
> very first line of my email, I understood my previous mistake in the
> early implementation of debian package. That's why I am doing it the
> 'right' way (as I have been suggested in the previous thread in this
> very same mailing list).
> The output of cmake will be a bunch of files: control,
> libfoo.install, so that you can run dpkg-buildpackage as any other
> debian package.

Stop. Don’t even try to go further. This is NOT the right way. Your
brand new wheels are going to drive you straight into a wall after way
too much effort.

> Why am I doing that ? Because *this is reinventing the wheel* when
> you use cmake and duplicate code in *.install file instead of simply
> asking cmake to generate those file for you. If you had read the wiki
> page I send, all the information is in the cmakelists, just not
> available as regular debian package files.

The cmakelists will not tell you in which package the files have to go.
And if they all need to go in the same package, you don’t need a
*.install file.

Most of the stuff in debian/ is NOT duplicating anything. It is the
required information to build a package.

> The other goal is to also export cmake dependencies (cmake is doing
> system inspection), so that one should not have to write the
> 'Build-Depends' line. cmake knows what is needs to compile, so indeed
> this line is purely machine generated.

There is no metadata store to map a build system’s requirements to
build-dependencies (unlike those we have for shared libraries). Some of
us have thrown some ideas to achieve that with pkg-config, but they
would be hacks. Achieving them with packages not using pkg-config (or a
similar system) does not even look possible in the current state of
affairs.

> As I said, I understand that some info (Conflicts typically) will be
> human generated, but I am sure that 95% of writing control/*.install
> file can be automatically generated by the build system: cmake in my
> case. As far as I understand generating those debian files can be
> tedious and error prone, plus it duplicate the logic in cmake anyway.
> This should remove most of the boiler plate code, when a project is
> using cmake.

Instead of trying to make funny and stupid things that will entertain us
for months, looking at you drowning in your brain-dead system, you
should try to write patches to make cdbs and/or debhelper 7 work
transparently with cmake. This is the right way, and it requires much
less effort than building a car with square wheels.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

On Mon, Jun 23, 2008 at 11:06 PM, Josselin Mouette <joss@debian.org> wrote:
> Le lundi 23 juin 2008 à 22:11 +0200, Mathieu Malaterre a écrit :
>> That's just rude. Even if you are a super star in the debian-world
>> and a fantastic hacker, your comment can not possibly be coming from a
>> grown up adult.
>
> Rude? Come on. You are trying to reinvent the wheel in the worst
> possible way, without understanding what a wheel is for and without
> obviously reading the documents that explain what are wheels and how to
> make them (Debian Policy and New Maintainer's guide). Starting from
> that, Frank could have been much more rude.

Fine.

>> You did NOT even try to make a tiniest effort to understand what I
>> am doing here. I am NOT reinventing the wheel here. As I said in the
>> very first line of my email, I understood my previous mistake in the
>> early implementation of debian package. That's why I am doing it the
>> 'right' way (as I have been suggested in the previous thread in this
>> very same mailing list).
>> The output of cmake will be a bunch of files: control,
>> libfoo.install, so that you can run dpkg-buildpackage as any other
>> debian package.
>
> Stop. Don't even try to go further. This is NOT the right way. Your
> brand new wheels are going to drive you straight into a wall after way
> too much effort.

Please give such real world examples of failure (if they are
documented anywhere).

>> Why am I doing that ? Because *this is reinventing the wheel* when
>> you use cmake and duplicate code in *.install file instead of simply
>> asking cmake to generate those file for you. If you had read the wiki
>> page I send, all the information is in the cmakelists, just not
>> available as regular debian package files.
>
> The cmakelists will not tell you in which package the files have to go.

I am the maintainer of this particular package. I made sure that
'cmake-components' actually match what I call a 'typical' debian
package: runtime libraries, application and dev package. Typically
cmake will also split installation into development type installation
vs runtime installation. So yes, there is a way to specify in cmake
what executable is part of which components (package in debian
vocabulary AFAIK).


> And if they all need to go in the same package, you don't need a
> *.install file.

what do you mean all ?

In cmake you simply say:

INSTALL(TARGETS tiffdump libtiff
RUNTIME DESTINATION bin COMPONENT Runtime
LIBRARY DESTINATION lib COMPONENT Runtime
)
INSTALL(FILES tiff.h
DESTINATION include COMPONENT Development
)

Which mean tiffdump and libtiff are part of the 'runtime' package,
while 'tiff.h' is part of the development package.(*)

Thus if you :

cmake -DCOMPONENT=Runtime -P cmake_install.cmake

It will only install the 'Runtime' components.

> Most of the stuff in debian/ is NOT duplicating anything. It is the
> required information to build a package.

That's what I call duplicate information:
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/gdcmutils.install?view=markup

This file could have been generated from the info contained in the
following cmakelists.txt

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Applications/Cxx/CMakeLists.txt?view=markup

while this file:

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/libgdcm20.install?view=markup

could have been generated from the info contained in the following
files (where * stand for Common, DataDict...):

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Source/*/CMakeLists.txt?view=markup

So the question is now: are the files debian/libgdcm20.install &
debian/gdcmutils.install the right way of doing it (I was suggested
the opensync package if that matter). Else how do you automatically
generate them, so that they are always in sink with the dev team ?

>> The other goal is to also export cmake dependencies (cmake is doing
>> system inspection), so that one should not have to write the
>> 'Build-Depends' line. cmake knows what is needs to compile, so indeed
>> this line is purely machine generated.
>
> There is no metadata store to map a build system's requirements to
> build-dependencies (unlike those we have for shared libraries). Some of
> us have thrown some ideas to achieve that with pkg-config, but they
> would be hacks. Achieving them with packages not using pkg-config (or a
> similar system) does not even look possible in the current state of
> affairs.

I do not understand this either. For instance, my cmakelists.txt
contains this particular line:

FIND_PACKAGE(ZLIB REQUIRED)

I thought I could just add an entry for the Build-Depends teling it
that zlib-dev will be required...

I understand that I may miss some (debhelper for instance), but
technically all dependencies should be listed in the cmake project.
Otherwise it's the developper's fault if they are missing a dep (and
not the packager's fault)

Please details your thought for simple cases.

>> As I said, I understand that some info (Conflicts typically) will be
>> human generated, but I am sure that 95% of writing control/*.install
>> file can be automatically generated by the build system: cmake in my
>> case. As far as I understand generating those debian files can be
>> tedious and error prone, plus it duplicate the logic in cmake anyway.
>> This should remove most of the boiler plate code, when a project is
>> using cmake.
>
> Instead of trying to make funny and stupid things that will entertain us
> for months, looking at you drowning in your brain-dead system, you
> should try to write patches to make cdbs and/or debhelper 7 work
> transparently with cmake. This is the right way, and it requires much
> less effort than building a car with square wheels.

Very funny.

Anyway, I have a working cmake-skeleton at least to automatically
generate the files in gdcm/debian/*, see:

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/

So I'll rephrase all my previous questions, into this single one: are
those files the right way of doing a debian package ?

Thanks for your time,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, 2008-06-24 at 00:20 +0200, Mathieu Malaterre wrote:
> > Stop. Don't even try to go further. This is NOT the right way. Your
> > brand new wheels are going to drive you straight into a wall after way
> > too much effort.
>
> Please give such real world examples of failure (if they are
> documented anywhere).

Cross-purposes.

Mathieu - you're coming from the viewpoint of a single package and
trying to make that apply to all packages that would use cmake.

Josselin is working from the viewpoint of all packages in Debian and
trying to make you see that the *right way* is to modify the existing
build tools to work with cmake.

I regularly have cause to review, modify, patch and mangle every build
system used in Debian (just about) and I have had to build a modified
build system around those systems that is able to support cross-building
via each one. The only way to do this is to supply modifications for
debhelper and CDBS, then make individual changes for individual packages
and get those changes filed as bugs in the BTS.

(Yes, I know many here hate CDBS but I say again, CDBS is the easiest
one for me to handle in such a way.)

Over the years, Emdebian and others have tried many other ways of doing
things, including your (doomed) attempt to scale up from a single
package. The right way is to extend debhelper to explicitly understand
cmake and use existing debhelper routines in a cmake-way.

> I am the maintainer of this particular package.

Then I respectfully submit that this is quite obviously the WRONG
package to select for this purpose.

Forget any specific package - work within debhelper alone and create a
system that works for all cmake projects using debhelper meta-data that
is entirely within the current scope of debhelper itself. By all means
test on a particular package (preferably many packages) but do *NOT*
base the entire thesis on a specific package - that way lies lunacy,
believe me. Been there, done that.

If debhelper understands cmake, CDBS will understand cmake via debhelper
and virtually every other build system in Debian will be able to make
the adjustment.

Do *NOT* stipulate that all cmake projects in Debian are expected to
generate their debian/ files using your scheme - reverse the logic and
make your scheme support all possible permutations of files in debian/
and provide the support required to implement those for cmake.

(If for no other reason than that people like me need to be able to
patch your debian/ files to make the package cross-build and comply with
Emdebian Policy without changes being overwritten by cmake.)

cmake is the object here, not the controller.

debhelper is the controller - cmake is the servant. Help the controller
understand how the servant works and get the servant to do things the
way that the controller stipulates.

> I made sure that
> 'cmake-components' actually match what I call a 'typical' debian
> package: runtime libraries, application and dev package. Typically
> cmake will also split installation into development type installation
> vs runtime installation. So yes, there is a way to specify in cmake
> what executable is part of which components (package in debian
> vocabulary AFAIK).

In which case the chances of the system matching any other package made
by a different upstream team approach zero.

> > There is no metadata store to map a build system's requirements to
> > build-dependencies (unlike those we have for shared libraries). Some of
> > us have thrown some ideas to achieve that with pkg-config, but they
> > would be hacks. Achieving them with packages not using pkg-config (or a
> > similar system) does not even look possible in the current state of
> > affairs.
>
> I do not understand this either. For instance, my cmakelists.txt
> contains this particular line:
>
> FIND_PACKAGE(ZLIB REQUIRED)

Insufficient. configure.ac contains lots of lines for finding libraries
and stuff. These lines are an *AID* to collating Build-Depends but not
the complete solution. A 100% calculated build-depends algorithm has not
yet been found.

> I understand that I may miss some (debhelper for instance), but
> technically all dependencies should be listed in the cmake project.

Wrong. You would also need to map Debian package names against upstream
names - many do differ. Other problems lie ahead - honest, this path is
doomed.

> Otherwise it's the developper's fault if they are missing a dep (and
> not the packager's fault)

Tosh.

> Anyway, I have a working cmake-skeleton at least to automatically
> generate the files in gdcm/debian/*, see:
>
> http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/
>
> So I'll rephrase all my previous questions, into this single one: are
> those files the right way of doing a debian package ?

A single package, maybe but it is still the wrong approach.

Get debhelper to work with cmake by making an interface between cmake
meta-data and debhelper meta-data. That is the mapping you need.

Give up generating the debhelper meta-data directly and just get
debhelper to understand how cmake expresses the meta-data and help
debhelper process the cmake data accordingly.

Automated package generation is a mugs game. Packaging for Debian is a
manual task.

--
Neil Williams <codehelp@debian.org>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-06-23, Josselin Mouette <joss@debian.org> wrote:
> for months, looking at you drowning in your brain-dead system, you
> should try to write patches to make cdbs and/or debhelper 7 work
> transparently with cmake. This is the right way, and it requires much

cdbs already works pretty well with cmake.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Jun 24, 2008 at 12:54 AM, Neil Williams <codehelp@debian.org> wrote:
> On Tue, 2008-06-24 at 00:20 +0200, Mathieu Malaterre wrote:
>> > Stop. Don't even try to go further. This is NOT the right way. Your
>> > brand new wheels are going to drive you straight into a wall after way
>> > too much effort.
>>
>> Please give such real world examples of failure (if they are
>> documented anywhere).
>
> Cross-purposes.
>
> Mathieu - you're coming from the viewpoint of a single package and
> trying to make that apply to all packages that would use cmake.

I do not believe I said cmake would take over the whole debian package
system tomorrow, but I see your point. Indeed, I am only focusing in
getting (in too little time) debian package for a particular set of
limited package.

> Josselin is working from the viewpoint of all packages in Debian and
> trying to make you see that the *right way* is to modify the existing
> build tools to work with cmake.
>
> I regularly have cause to review, modify, patch and mangle every build
> system used in Debian (just about) and I have had to build a modified
> build system around those systems that is able to support cross-building
> via each one. The only way to do this is to supply modifications for
> debhelper and CDBS, then make individual changes for individual packages
> and get those changes filed as bugs in the BTS.
>
> (Yes, I know many here hate CDBS but I say again, CDBS is the easiest
> one for me to handle in such a way.)

I had to work the other way around. Install cmake-based project via
official debian package, only to realize installation was broken.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486794

That's were I started to think of a better collaboration in between
debian package system and cmake...

> Over the years, Emdebian and others have tried many other ways of doing
> things, including your (doomed) attempt to scale up from a single
> package. The right way is to extend debhelper to explicitly understand
> cmake and use existing debhelper routines in a cmake-way.

THANK YOU !
So far I only had FUDs about: 'no this is impossible, 'this is not the
right way'. Thanks for taking the time to answer in detail, this much
more supportive. I finally understood the previous aggressive answers,
I was simply looking at the problem from opposite direction.
So the next question is: where do I get started

>> I am the maintainer of this particular package.
>
> Then I respectfully submit that this is quite obviously the WRONG
> package to select for this purpose.

Yeah well, say that to upper management
Sorry been under too much pressure, I'll give up on my half born
project cmake-driven debian package generation and start looking into
integrating cmake into debhelper.

> Forget any specific package - work within debhelper alone and create a
> system that works for all cmake projects using debhelper meta-data that
> is entirely within the current scope of debhelper itself. By all means
> test on a particular package (preferably many packages) but do *NOT*
> base the entire thesis on a specific package - that way lies lunacy,
> believe me. Been there, done that.

ok.

> If debhelper understands cmake, CDBS will understand cmake via debhelper
> and virtually every other build system in Debian will be able to make
> the adjustment.
>
> Do *NOT* stipulate that all cmake projects in Debian are expected to
> generate their debian/ files using your scheme - reverse the logic and
> make your scheme support all possible permutations of files in debian/
> and provide the support required to implement those for cmake.

Ok. I'll need to learn debhelper terminology.

> (If for no other reason than that people like me need to be able to
> patch your debian/ files to make the package cross-build and comply with
> Emdebian Policy without changes being overwritten by cmake.)
>
> cmake is the object here, not the controller.
>
> debhelper is the controller - cmake is the servant. Help the controller
> understand how the servant works and get the servant to do things the
> way that the controller stipulates.

ok.

>> I made sure that
>> 'cmake-components' actually match what I call a 'typical' debian
>> package: runtime libraries, application and dev package. Typically
>> cmake will also split installation into development type installation
>> vs runtime installation. So yes, there is a way to specify in cmake
>> what executable is part of which components (package in debian
>> vocabulary AFAIK).
>
> In which case the chances of the system matching any other package made
> by a different upstream team approach zero.



>> > There is no metadata store to map a build system's requirements to
>> > build-dependencies (unlike those we have for shared libraries). Some of
>> > us have thrown some ideas to achieve that with pkg-config, but they
>> > would be hacks. Achieving them with packages not using pkg-config (or a
>> > similar system) does not even look possible in the current state of
>> > affairs.
>>
>> I do not understand this either. For instance, my cmakelists.txt
>> contains this particular line:
>>
>> FIND_PACKAGE(ZLIB REQUIRED)
>
> Insufficient. configure.ac contains lots of lines for finding libraries
> and stuff. These lines are an *AID* to collating Build-Depends but not
> the complete solution. A 100% calculated build-depends algorithm has not
> yet been found.

I still do not understand this one. cmake is able to say I need
'zlib.h' and 'z.so', so I do not see why this is so hard to find out
that zlib-dev is required (dpkg -S, or equivalent call), right ?

>> I understand that I may miss some (debhelper for instance), but
>> technically all dependencies should be listed in the cmake project.
>
> Wrong. You would also need to map Debian package names against upstream
> names - many do differ. Other problems lie ahead - honest, this path is
> doomed.

ok.

>> Otherwise it's the developper's fault if they are missing a dep (and
>> not the packager's fault)
>
> Tosh.
>
>> Anyway, I have a working cmake-skeleton at least to automatically
>> generate the files in gdcm/debian/*, see:
>>
>> http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/
>>
>> So I'll rephrase all my previous questions, into this single one: are
>> those files the right way of doing a debian package ?
>
> A single package, maybe but it is still the wrong approach.
>
> Get debhelper to work with cmake by making an interface between cmake
> meta-data and debhelper meta-data. That is the mapping you need.
>
> Give up generating the debhelper meta-data directly and just get
> debhelper to understand how cmake expresses the meta-data and help
> debhelper process the cmake data accordingly.
>
> Automated package generation is a mugs game. Packaging for Debian is a
> manual task.

I was only targeting at getting part of the work done. Anyway I'll
start looking into debhelper ASAP.

Anyway, that was very instructive, thanks for your time.

--
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le mardi 24 juin 2008 Ã* 00:20 +0200, Mathieu Malaterre a écrit :
> > Stop. Don't even try to go further. This is NOT the right way. Your
> > brand new wheels are going to drive you straight into a wall after way
> > too much effort.
>
> Please give such real world examples of failure (if they are
> documented anywhere).

There are no such examples, because nobody has yet been foolish enough
to do such a thing. In fact, if I ever see such a package passing
through NEW, I’ll drive straight to Germany and hunt down the alien that
took over Ganneff’s body.

> I am the maintainer of this particular package. I made sure that
> 'cmake-components' actually match what I call a 'typical' debian
> package: runtime libraries, application and dev package. Typically
> cmake will also split installation into development type installation
> vs runtime installation. So yes, there is a way to specify in cmake
> what executable is part of which components (package in debian
> vocabulary AFAIK).

In which case, what you need is simply to run cmake commands to install
the different sets of files into different installation directories (one
per package). No need to generate any file.

> > Most of the stuff in debian/ is NOT duplicating anything. It is the
> > required information to build a package.
>
> That's what I call duplicate information:
> http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/gdcmutils.install?view=markup

There are two possibilities here: either the maintainer lists all files
in /usr/bin, in which case he is a masochistic since putting
only /usr/bin would have been enough; either only a selected set of
files has to be installed, and you have to list which ones, so this is
no duplication.

> So the question is now: are the files debian/libgdcm20.install &
> debian/gdcmutils.install the right way of doing it (I was suggested
> the opensync package if that matter). Else how do you automatically
> generate them, so that they are always in sink with the dev team ?

For most packages, these files get modified only after important
upstream changes.

> > There is no metadata store to map a build system's requirements to
> > build-dependencies (unlike those we have for shared libraries). Some of
> > us have thrown some ideas to achieve that with pkg-config, but they
> > would be hacks. Achieving them with packages not using pkg-config (or a
> > similar system) does not even look possible in the current state of
> > affairs.
>
> I do not understand this either. For instance, my cmakelists.txt
> contains this particular line:
>
> FIND_PACKAGE(ZLIB REQUIRED)
>
> I thought I could just add an entry for the Build-Depends teling it
> that zlib-dev will be required...

This is too naive. You will not be able to get build-dependencies for a
library with a libfoo-config, nor to compute the minimum required
version of a library so that a specific function which is checked for is
available. Apart from those using pkg-config, there are as many ways to
detect a libray as libraries.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.