| Stephen Frost 2005-07-15, 7:53 am |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> 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
|