Bug#577209: libdbi-perl: DBI<>DBD ABI change breaks partial upgrades

[Niko Tyni]

On Mon, Apr 12, 2010 at 04:38:58PM +0200, gregor herrmann wrote:
> On Mon, 12 Apr 2010 08:51:55 +0300, Niko Tyni wrote:
> 
> > On Sun, Apr 11, 2010 at 10:54:30PM +0300, Niko Tyni wrote:
> > > The sid breakage should be gone with the binNMUs, but I think the partial
> > > upgrade issue is RC, so reopening and reassigning.
> > One option to fix the breakage and get a controlled transition later is
> > to upload the older libdbi-perl with an epoch and do binNMUs again, That
> > still means sourceful uploads for libdbd-mysql-perl and libdbd-csv-perl,
> > which already had their dependencies bumped.

(Correction: no sourceful uploads would be necessary for this step.
 libdbd-csv-perl is arch:all and therefore not affected by the issue.
 The current libdbd-mysql-perl version could be reverted back to the old
 ABI level (94) with a binNMU against the epoch'd libdbi-perl 1:1.609-1
 just like all the others.)

The binNMUs that have already migrated (at least libdbd-sybase-perl,
libdbd-odbc-perl, and libdbd-sqlite2-perl on some architectures) are
currently broken in squeeze.

Unfortunately any new binNMUs are going to get stalled behind perl
5.10.1-12, which I uploaded last night with urgency=low, so quick
fixes for squeeze seem to be impossible anyway.

> Right; IMO doing it right now would be better; reverting the change
> also leads to work and postpones the transition only.

Do we really want to have a DBI development release in squeeze?
It doesn't seem to be actually needed for anything. If we don't
want it, postponing the transition becomes a positive effect.

I think that the epoch option would get squeeze into a releasable state
quicker, but it's possible that I'm overengineering all this.

The additional work with the epoch option is "only" binNMUs, and the
number of sourceful uploads stays the same AFAICS.

The summary as I see it:

Plan A: "don't look back"

(A0. wait for libdbi-perl 1.610.90-1 and all the current binNMUs to enter
     squeeze to fix the immediate breakage)
A1. upload libdbi-perl 1.610.90-2 that Provides: perl-dbdabi-95 and possibly
    Breaks: libdbd-*-perl versions older than the current binNMUs
A2. get sourceful uploads done for all the libdbd-*-perl packages
    adding a (preferrably binNMU safe) dependency on perl-dbdabi-95

 When these get in squeeze we're probably non-RC, but things may be
 difficult for derivative distributions and stable updates.
 That can be fixed by

A3. upload libdbi-perl 1.610.90-3 that Breaks: all the libdbd-*-perl
    packages earlier than A2

Plan B: "revert for now"

B1. upload libdbi-perl 1:1.609-2 that Provides: perl-dbdabi-94
B2. binNMU libdbd-*-perl; wait until the currently broken binNMUs in
    squeeze are superseded

 At this point I think we're non-RC, effectively at square one. We can
 now prepare the transition properly:

B3. file bugs to get a binNMU safe perl-dbdabi-N dependency, into
    libdbd-*-perl, N==94 at this point
B4. once those are fixed, upload libdbi-perl 1:1.610.90-2 (or a later
    real release if that's preferred) that Provides: perl-dbdabi-95 and
    Breaks: libdbd-*-perl versions older than B3.
B5. then binNMU the libdbd-*-perl packages to update them to
    perl-dbdabi-95

While I'm certainly arguing for plan B here, I'm open to persuasion :)
Please point out any mistakes, my head hurts after all this.

I'm of course willing to help (time permitting) with the implementation
of any scheme that gets this issue fixed once we have consensus.
-- 
Niko Tyni   ntyni at debian.org