* Junichi Uekawa (dancer@netfort.gr.jp) wrote: > 1. Conclusion: > For the initial question of > 'How does one decide which -dev package accompanies > runtime library package' > There is no answer, and we have not reached the consensus. It would be possible to put forth a proposal to deal with this, but it needs to be something sensible. Putting the SONAME in the -dev package isn't sensible. Perhaps something like: libfooAPI-dev ; libfooAPI-SONAME This is being done already, though 'API' is often just a major revision number associated with the library. ie: libglib2.0-dev ; libglib2.0-0 So, pull off the stuff after the last -[0-9]* and add -dev and you've got the -dev package. I'm not sure there's enough packages doing this to make it policy, but you could try to get people to accept it for new libraries and convince existing maintainers to move to it. > 3. -dev package names reflect API and runtime library packages reflect ABI? > > Apparently so, and sounds like a good idea that most people > agree on, there wasn't a real objection to this idea > modulo bugs on packages. Bugs are bugs, and need to be fixed. > 4. -dev packages should depend on other -dev packages? > > Yes. Whoah, whoah, whoah. This is just blatently false. There *certainly* wasn't a consensus that -dev packages should regularly depend on -dev pacakges. There's a couple corner cases where it's required (because the headers of one #include's headers from the other) but that definitely doesn't deserve a 'should'. In fact, even those cases should generally be discouraged. > Stephen Frost argued in this thread that -dev packages do not need to > depend on other -dev packages, but due to > things such as header files and libtool, > there are cases which -dev packages depending on > other -dev packages are rquired. -dev packages depending on -dev packages should generally be avoided. It's true that if a -dev package includes header files from another -dev package then it does need to depend on it. Thankfully, this is rare. Generally it should be discouraged because it means that you've got two different APIs involved which just gives the opportunity for more bugs. Honestly, these cases should be carefully reviewed and discussed with upstream as to if they understand the implications of it. libtool is broken in this regard and needs to be fixed to survive missing files. libtool's brokenness just isn't a good enough reason to introduce all these -dev -> -dev dependencies. The static linking argument is pretty much dead. There was some discussion about having a -dev (headers only) and a -static (static libs plus libtool cruft, w/ dependencies on other -static packages, etc) package for each library but basically that'd really just be a stepping stone to then later drop the -static packages. Not sure there's really any point doing the transistion to that just to drop it. Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature