"Mathieu Malaterre" <mathieu.malaterre@gmail.com> wrote: >
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 :)
My gut alos told me that you were going at it the wrong way, but It was not until I read this, that I realized what the right way was. debhelper extracting the usuable information, and creating the files. This would potentially then support two ways of working. If the debhelper support is complete enough, the generic debhelper buildscript is all that would be needed. The contents of the binary packages could potentially be determined by by the INSTALL(...) commands, which apparently support multiple packages.
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 ?
That system may work in quite a few cases, but would not nessisarally work in all cases.
However, it is perfectly possible to have the dh_make (the script that initially creates a debhelper-based debian/ directory) do a preliminary pass, and determine as many of the build depends needed as possible. Then anything it did not catch could be added manually.
(Actually a new non-buildtime script that dh_make would call would probably work better. This seperate program could be used by the maintainers to update the build-depends with any new packages it can detect. The idea being that in at least some cases, new build-depends could be automatically added.)
Anyway, the best way to become familar with debhelper is to use it to package a few simple traditional make based packages. Then jump in. Keep in contact with the Debhelper maintainer (Joey Hess) and dh-make's maintainer (Craig Small).
Hope this message has helped in some way.