Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)
Junichi Uekawa <email@example.com> writes:
>> > 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.
If libB1 and libB2 are only an ABI change but not an API change then
libA will just compile and then have a Depends: libB2
automaticaly. That is fully intentional.
If libB1 and libB2 have different APIs then the libB maintainer
screwed up. API changes must eigther be reflected in the
libB<api_number>-dev name (e.g. libpng2-dev, libpng12-dev) or the
maintainer must make damn sure all rdepends are updated along with
Since several people have started to infrequently recompile all of debian
to see if any sources broke any violations of this will get noticed.