[pkg-otr-team] Bug#767230: libotr transition started by mistake :-/ [Was: Bug#767230: bitlbee-plugin-otr: bitlbee no longer starts: libotr API version 4.1.0 incompatible with actual version 4.0.0]

[intrigeri]

Hi Sebastian, hi release team,

RT: this is about #767230, that just got reaffected to libotr.
The problem was nicely summed up by Sebastian on that bug, and below
I'm summing up what I believe are our three options. I'd like to know
which one(s) would be acceptable for you.

Sebastian Ramacher wrote (29 Oct 2014 14:43:44 GMT) :
> Calling OTRL_INIT is apparently the recommend way to initialize libotr.
> However, this causes issues if a program is built against libotr 4.1 but
> used with libotr 4.0 as it just happend to bitlbee-plugin-otr. The
> package built against libotr 4.1.0 migrated to testing before libotr
> 4.1.0-1 since the appropriate versioned dependencies are missing.

> The attached patch uses shlibs to generate the proper dependencies.

Thanks, Sebastian, for the analysis and the patch!
(RT: that patch adds a dh_makeshlibs call to the packaging.)

I'm sorry for having uploaded libotr 4.1 without having checked more
carefully how it impacted reverse-dependencies: I did ask upstream
whether it broke the API or ABI (answer: no), and manually checked
that it did not remove/change existing symbols. Too bad the library
does this runtime version check, that I was not aware of :(

(If I were mean, I would argue that reverse-build-deps of a library
that lacks shlibs *and* does this check at runtime are themselves
responsible for having tighter dependencies on the version library
they really need to work fine. But oh well, of course the root of the
problem lies in the lack of shlibs support in the libotr packaging, so
I'll shut up, take my share of the blame, and try to fix things up :)

Anyway: it seems that I've actually started a transition after the
transition freeze :/

Useful facts:

  * libotr 4.1.0-1 will migrate to testing in 3 days, unless we
    prevent this from happening; same for pidgin-otr 4.0.1
  * libotr 4.1 fixes quite some bugs, some of them having security
    implications
  * pidgin-otr 4.0.1 also fixes quite some bugs, and improves a lot
    of previously crappy translations
  * These two new upstream releases were prepared at my request,
    because I strongly felt that we needed the bugfixes sitting in
    upstream's Git repo into Jessie. Then, upstream gently took into
    account Debian's freeze schedule. Granted, we should have planned
    all this earlier, to leave more time to handle potential problems.


So, I guess we have three different options from now on:

Plan A -- ship Jessie with libotr 4.1, drop the version check temporarily
=========================================================================

1. Patch libotr to loosen this version check on Jessie: assuming the
   "no API/ABI break" assumption is true, this should work just fine.
2. For Jessie+1, re-add the version check, and get proper shlibs
   support so that we get proper transition handling next time.

Pros:

  * Very simple, no disruptive change, reverse-deps go work again
    regardless of whether they've been built against libotr 4.0 or 4.1
  * Less work for everyone affected.

Cons:

  * Ugly?
  * This requires letting libotr 4.1 migrate with this change in at
    some point. Either let it migrate in 3 days in its present form
    (arguably buggy, although the reverse-build-deps have their share
    of responsibility for missing versioned deps they need), and then
    get a unblock for dropping the version check. Or dropping the
    version check in sid right now, and getting an unblock for the
    whole thing later.

Plan B -- complete the transition, ship Jessie with libotr 4.1
==============================================================

(Keep in mind that I've no experience with transitions, so this plan
may very well be flawed. Below, I'm assuming we can't binNMU packages
in testing.)

1. binNMU against libotr 4.1 all affected reverse-build-deps that were
   built against libotr 4.0.
2. Wait for libotr 4.1 to migrate to testing.
3. Let the binNMU'ed reverse-build-deps migrate to testing too.

(And optionally, get a libotr 4.1 with proper shlibs support into
testing, and binNMU reverse-build-deps so that partial upgrades work
fine. That would require a freeze exception. Not sure it's worth it.)

Pros:

  * No need to manually deal with getting the fixes from libotr 4.1
    and pidgin-otr 4.0.1 into Jessie => not too much work for me, and
    for the RT.

Cons:

  * Step #3 can be an issue, if some reverse-build-deps have been
    uploaded to sid with changes that are not compatible with the
    freeze policy already. If this was the case, some of them might
    need to go through t-p-u to get in practice what a binNMU in
    testing would give us. Not checked this part yet. Should I?

Plan C -- cancel the transition, ship Jessie with libotr 4.0
============================================================

1. Prevent libotr 4.1 and pidgin-otr 4.0.1 from reaching testing.
   I guess the best would be to revert libotr to 4.0 in sid, otherwise
   new uploads of reverse-build-deps will be built against libotr 4.0,
   and either will be buggy (by missing the correct versioned runtime
   deps) or won't be able to get freeze exceptions (because they'll
   depend, for all practical means, on a package that we'll want to
   keep out of testing).
2. binNMU (against libotr 4.0) any reverse-build-deps that has been
   built against libotr 4.1 already.

Pros:

  * less disrupting changes for Jessie, that is left in its current
    state
  * Not much work needed for the RT right now (only a few binNMUs).

Cons:

  * I'll have to find other ways to get the bugfixes from libotr 4.1
    and pidgin-otr 4.0.1 into Jessie. Lots of wasted time for me.
    I'd rather spend it on reviewing unblock requests ;)
  * More future unblock requests for libotr and pidgin-otr to deal
    with on the RT's side.

My preferred option is plan A, because it seems to be simpler for
everyone affected. Plan B would be fine with me too. Option C would
make me sad, and add painful work for everyone involved further along
the road.

Dear RT, what option(s) would be acceptable for you?

Sorry for the burden again..

Cheers!
-- 
intrigeri