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

Re: libpkg-guide updated (versioned symbols), please proofread



* Junichi Uekawa (dancer@netfort.gr.jp) 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).

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

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.

As I recall, libdb doesn't actually use versioned symbols anymore but
instead uses a hack because versioned symbols aren't supported on all
architectures.

Using -Bsymbolic is just a bad idea in general, and should be avoided.

I think that's it, though there's probably some other stuff I missed.

	Stephen

Attachment: signature.asc
Description: Digital signature


Reply to: