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

[Ian Goldberg]

On Sat, Nov 01, 2014 at 06:19:16PM +0100, intrigeri wrote:
> >   * Generate and maintain a symbols file.
> 
> Note that this is enough if, and only if, we don't reintroduce
> upstream's runtime version check (which we're going to remove for
> Jessie). If we reintroduce this check, reverse-deps compiled against
> a new version of the library won't be able to run against an older
> version of the library, unless they use symbols introduced by the new
> version (and thus explicitly depend on it).

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.

In the 3.x series, for example (the Debian libotr2 package), elements
were added to the OtrlMessageAppOps data structure between 3.0 and 3.1.
It was backwards compatible, in that an application compiled with 3.0
could use a 3.1 runtime just fine, but the opposite isn't true: if an
application was compiled with 3.1, it could not use a 3.0 runtime.
That's why that runtime check is there.  Applications that compile
against libotrN X.Y.Z should declare a dependency on libotrN >= X.Y.0,
right?  [X cannot change without N also changing, of course.]

The 4.0 -> 4.1 transition I admit was a weird case.  There were two
functions in 4.0 that weren't meant to be exported, but were probably
visible anyway.  In 4.1 they were officially exported.  So the list of
symbols didn't change, even though it was "supposed" to.

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?

But I admit I'm not completely clear on the Debian rules for all this,
so please clarify if I'm misunderstanding something.

Thanks,

   - Ian