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.
signature.asc
Description: Ceci est une partie de message numériquement signée
