On 07/06/2016 10:36 AM, Gianfranco Costamagna wrote:
> all the symbols have been updated:
> e.g.
>
> [snip]
>
> - u2fh_check_version@U2F_HOST_0.0 0.0
>
> + u2fh_check_version@U2F_HOST_0.0 1.0
That's a change in the minimum version of the symbol, but not the
symbol name itself (that's still the same). To me, this looks very,
very wrong.
So what happens with .symbols is that dpkg-shlibdeps looks through
every binary and library of a package and then tries to figure out
against what they were linked. Then it looks up the package these
libraries come from, and then looks at the shlibs and symbols files of
those packages. It then uses that information to figure out how to
generate the proper Depends: entries for the generated binary packages.
For example:
Package libfoo0 contains shared object libfoo.so.0
The package's symbols file contains:
foo_a@BASE 1
foo_b@BASE 2
If you then package a program baz that links against libfoo.so.0,
then dpkg-shlibdeps (and by extension dh_shlibdeps) will generate a
dependency via ${shlibs:Depends} on libfoo0. However, there are two
possibilities how it generates that dependency:
Depends: libfoo0 (>= 1)
(if only foo_a() is used)
Depends: libfoo0 (>= 2)
(if foo_b() is used, irrespective of foo_a())
This makes sure that if you introduce a new symbol in a new library
version, the dependencies built against that library get the proper
binary package depdendencies added with the proper minimum version.
A software that is built against a newer libfoo0 will still work with
the older libfoo0, if it doesn't use new functionality - and then you
want to have the dependency that's added to not force a newer version
unless really necessary. (This allows e.g. baz to enter testing even
if the newer version of libfoo0 it was built against hasn't yet for
various reasons, as long as the older libfoo0 it actually needs is
still available in testing.)
So the version number after the symbol is actually the upstream package
version number (without the -DEBIAN_SUFFIX), to make sure that the
right library dependency is added automatically.
If you have a symbol in a file, in the vast majority of cases, you
should NEVER update the minimum version of that symbol. Why?
- Either that symbol is still compatible with the previous version, in
which case you should keep the older version there.
- Or the symbol isn't compatible anymore, but then you should have a
SONAME bump (e.g. libfoo.so.0 -> libfoo.so.1) and a transition that
you need to coordinate with the release team, because then older
software won't work either with the newer library.
There is a corner-case in which a symbol is forward-compatible
(binaries compiled against the older lib work with the newer one), but
not the other way around, in which case you should update the minimum
version (so that packages built against the newer version make sure
they depend on the newer version), but that is _very_, _very_ rare, and
typically that would only affect very few symbols, not all of them.
So to me, this looks really wrong. The initial version in Debian was
0.0.4, so 0.0 seems to be the right minimum version for the symbols. So
this should _not_ be changed (or maybe only be changed to 0.0.4 to
reflect the first version in Debian). But putting 1.0 there for the old
symbols is something that should not happen, unless you really run into
the rare case of forward-only-compatibility. (I doubt it, though I
haven't looked at it.) Only _new_ symbols should get the 1.0 minimum
version.
As for reverse dependencies: you don't need to compile them in either
case: either the dependency that was added is wrong (likely) and it
should still be 0.0 there for the _old_ symbols, then the revdeps
already have the correct Depends: ... (>= 0.0), or you have really run
into this forward-only-compat case (unlikely) and then having packages
built against the old library is still fine, so you don't need to
rebuild them. (You should just make sure that they do build against
the new version and haven't started to FTBFS.)
Or, if the symbols really are completely incompatible, then this is
all wrong, because then you (or rather: upstream) would actually either
need to bump the soname, or, since the library already uses versioned
symbols, convince upstream to introduce multiple versions of the same
symbols (with different version tags) to remain binary compatible, and
then you'd need to add the added symbols (with the correct minimum
version) to the symbols file. (And if upstream decides to go for a
soname bump, you'd need a transition slot by the release team.)
Hope that helps.
Regards,
Christian
Attachment:
signature.asc
Description: OpenPGP digital signature