[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SUMMARY: Re: shared library -dev package naming proposal

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



Attachment: signature.asc
Description: Digital signature

Reply to: