* Junichi Uekawa (dancer@netfort.gr.jp) wrote: > > > BTW, having Build-Depends: libfoo-dev in > > > a library's build-deps, will allow the developer > > > to overlook a soname change in depending shared library. > > > Which is a bad idea in the QA standpoint. > > > > Yes and no. > > > > The programer can overlook the soname change for the source. The API > > hasn't changed and nothing needs to adjust for the new soname. > > > > The packaging system won't let the binary forget the soname change > > though as that is part of the package name of the libary. Binaries > > will keep using the old lib till they are recompiled. > > I'm talking about the following case: > > 1. libA depends on libB1, but only build-depends on libB-dev > 2. libB1 changes to be libB2. > 3. libA is rebuilt with libB2 without maintainer noticing (could happen > on buildd, etc.), possibly creating a noncompatible interface. > > It would be a practical case especially when libB1, libB2 are not > using versioned symbols. Versioned symbols has nothing to do with this case. If the API changes (what you're talking about above) then perhaps the -dev name should change. Tieing the -dev name to the SONAME (ie: A*B*I) is not an appropriate fix for dealing with API changes. Quite a few packages already handle this by having a version in the name of all the packages, and then having a *seperate* incremented number in the name of the lib package for the SONAME. That's the correct way to solve this problem, not trying to tie the ABI and the API together. In fact, I believe glib2.0 is an example of this: glib2.0-0 - The actual library, with the '0' revision of the ABI glib2.0-dev - The headers, ie: API, for glib2.0. This essentially says that the A*P*I for glib2.0 won't change in a backwards-incompatible way. If it does, then it's a bug and needs to be fixed. This does allow for A*B*I changes, which require only a recompile of the application (because the API hasn't changed). Now, there is a seperate issue with libtool-using libraries and .la dependencies, but that's exactly what it is, a seperate issue. Stephen
Attachment:
signature.asc
Description: Digital signature