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

Re: shared library -dev package naming proposal

* Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> > If this is actually necessary for libtool-using packages, then write
> > something which goes through all of the .la files and does this, since
> > that's what libtool wants to do.
> and 
> > Errr, you still havn't said what problem you're trying to solve 
> > with this yet.
> 1. To derive dependency information from libtool-using packages,
>   it is currently possible to derive lists of shared library packages.
> 2. In general, there is a leap in shared library packages and -dev package,
>   and it's not possible to get a -dev package which is for a given
>   shared library package.

Shared library packages and -dev packages represent different things.

> I envision that it would be nice to be able to agree on some kind of 
> naming style so that it is possible to deduce the name of development
>  library in some mechanical manner. It's not just because of autogenerating
> -dev dependencies, but about usability of Debian as a Development 
> platform :
> $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
> libshared0-dev

Having a single naming style is somewhat difficult for libraries because
different upstreams choose to represent API changes differently.  An
example of this is OpenLDAP- their API hasn't ever changed in a
backwards-incompatible way (or so they tell me).  They do add things to
their API over time, though I think they generally try to do those
around major releases (2.0, 2.1, 2.2, 2.3, etc).  They also change the
ABI without (unfortunately) much hesitation.  The ABI changes need to be
tracked using the SONAME, but technically we could have just one
'libldap-dev' since OpenLDAP 1.3.  This isn't true for other upstreams,
such as glib, which, I infer from their naming scheme anyway, has API
changes generally around major releases, and those changes aren't
backwards-compatible. (ie: 1.3 to 2.0, or what have you).

Tieing the API to the SONAME is a *bad* idea, it implies changes where
there aren't any and requires changes to packages that aren't necessary.
Honestly, I think it'd be nice if we could teach the buildds to
automatically rebuild packages when the API hasn't changed.  I'd think
that'd make some of these transistions that we have to go through on
occation go alot faster.

> An alternate solution is to have a database for that kind of thing, 
> but I forsee that it requires effort to maintain and keep up-to-date.
> It's rather embarassing to know that Debian isn't organized at all in this
> manner.

Back to my previous comment- you've got people who aren't familiar with
SONAMES and ABIs writing libraries.  I don't feel that's *Debian's*
fault, though we do try to deal with it as best we can.  This suggestion
doesn't help that issue one bit though.


Attachment: signature.asc
Description: Digital signature

Reply to: