Re: release policy changes
Russ Allbery <rra@stanford.edu> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>> mrvn@frosties:~% apt-cache show mozilla-dev
>> Package: mozilla-dev
>> Architecture: amd64
>> Source: mozilla
>> Version: 2:1.7.8-1
>> Depends: mozilla-browser (= 2:1.7.8-1), libnspr-dev (= 2:1.7.8-1), libxt-dev, libc6 (>= 2.3.2.ds1-21), libgcc1 (>= 1:3.4.1-3), libglib2.0-0 (>= 2.6.0), libidl0, libstdc++6 (>= 3.4.3-1)
>
>> As you can see clearly from the Depends the package was build against C
>> ABI from 1:3.4.1-3 and C++ ABI from 3.4.3-1. All dynamic libraries must
>> have those Depends or they already violate policy. And that version maps
>> to an uniqe ABI.
>
> I think you're confusing the C++ ABI with the SONAME of libstdc++.
> They're not necessarily the same thing, although right now they tend to
> change at the same time. Having the SONAME of libstdc++ change is
> actually probably more likely to cause problems than a C++ ABI change
> (since the latter is likely to be an edge case at this point), but either
> can cause problems.
If libstdc++ changes its ABI without its SONAME then every package
linked against it most likely breaks. That certainly wouldn't do.
If the ABI changes but not the SONAME then the only sane thing to do
is to encode the ABI in the package name, e.g. libstc++-6c1002. Just
like for any other lib doing the upcoming c++ abi transition.
So what I ment to say is that the package name changes. SONAME can
stay the same, but not the package name. That would cause untold
chaos.
As a sidenote, even if the package name stays the same the shlibs file
should have a never version and that would show up in the Depends line
again. But that would be an obscure way to detect it.
MfG
Goswin
Reply to: