Re: libpkg-guide updated (versioned symbols), please proofread
Thanks for your comments.
> [1 <text/plain; us-ascii (quoted-printable)>]
> * Junichi Uekawa (firstname.lastname@example.org) wrote:
> > I would like some feedback, if this works, if it's unclear, if it's
> > misleading.
> Alright, some additional corrections (didn't I do this before?):
> Packages which contain multiple shared libraries are fine provided they
> don't unduly increase the amount of crap that needs to be updated (such
> as existed with xlibs) and handle compatibility issues (as libc6 does).
I'll write a footnote on that topic.
However, as an introductory guide to shared library packaging,
that is rather much of a gory detail.
> -dev packages should *NOT* depend on other -dev packages unless their
> public .h files #include files from those other -dev packages (which
> generally shouldn't be the case). That whole crap was due to the lack
> of understanding of the problem and blindness to the proper solution
> (versioned symbols). The result is that it just makes things FTBFS and
> doesn't actually fix the problem anyway. Not exactly useful.
This part does not entirely apply to Debian since we keep static libraries
and try to keep them useful. I've added notes on why the Depends is
actually required for the functioning of a -dev package.
o for static linking
o for header files and inclusions
> Build-Depend's should be *accurate* in that they map to the *API* that's
> required. Sometimes this works out as being the same as the SONAME, but
> that's not always the case. Multiple ABI's can be associated with a
> single API. This is actually the case with OpenLDAP which claims, at
> least, to have not broken backwards compatibility with the API since the
> 1.x days, though the ABI has changed a number of times. Of course, if a
> package depends on parts of the API that were added later they should
> version their build-depends appropriately. In general it'd probably
> actually be good to get away from having version numbers in -dev package
> names based on the expectation that upstream will be similar to the
> OpenLDAP case, and in the event that the API is changed in a way which
> is not backwards compatible the library name may be changed in some
> other way.
I'm not quite sure what portion of libpkg-guide this comment
> Using -Bsymbolic is just a bad idea in general, and should be avoided.
I've added a note there to use symbol versioning instead.
Nice to see feedbacks :)