* 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. Stephen
Attachment:
signature.asc
Description: Digital signature