[pkg-otr-team] Bug#767652: libotr5: Generate versionned dependencies for reverse-dependencies

[intrigeri]

Hi Ian,

Ian Goldberg wrote (01 Nov 2014 18:15:28 GMT) :
> But don't you *want* programs compiled against, say, 4.2, not to be able
> to run with, say, 4.0?  If it's compiled against 4.2, even if it doesn't
> use functions added in 4.2, it may use data structures that have
> changed.

Sure.

When relying on a symbols file, the maintainer of the Debian package
is responsible to check for changes in data structures, and bump the
needed version in the symbols file for every function that uses one of
the data structure that has changed.

This way, reverse-dependencies always depend on the minimal version of
libotr they really need, and we can use the generic Debian library
transition mechanism to rebuild only those that need it.

Of course, there's some room for human error here. I've documented
this process in debian/README.source to decrease the chances someone
updates the package without doing the needed checks.

> So it's likely OK to change the runtime change to special case "app
> compiled against 4.1 using 4.0 runtime is OK", but I don't think the
> runtime check should be removed in perpetuity?

Once we have the symbols mechanism [1] in place:

  * The runtime check is not needed anymore, as the symbols mechanism
    achieves the same purpose.

  * We can *not* keep the runtime check, as it will break
    reverse-dependencies every now and then, while they can
    effectively work fine with the new version of the library. (This
    is not a theoretical question, as it has just happened.)

[1] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols

Cheers,
-- 
intrigeri