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

gregor herrmann gregoa at debian.org
Mon Apr 12 21:31:33 UTC 2010


On Mon, 12 Apr 2010 21:49:56 +0300, Niko Tyni wrote:

> > > 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.)

Ack.
 
> 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.

Oops, I hadn't realized how fast binNMUs migrate.
 
> > 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 in general we don't want development releases, and this one
was a (wrong) exception ...
 
> Plan A: "don't look back"
>  When these get in squeeze we're probably non-RC, but things may be
>  difficult for derivative distributions and stable updates.

Good point.

> Plan B: "revert for now"
> B4. once those are fixed, upload libdbi-perl 1:1.610.90-2 (or a later
>     real release if that's preferred) 

A real release would be preferrable IMO.

> 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.

My head hurts, too, and that only after reading :)
Thanks for taking the time to analyze this mess!

(Maybe someone else still reading along with less headache also has
some thoughts?)


After reading through the two plans now for the fifth time, I think
plan B brings a "stable" state earlier, since plan A relies on the
sourceful libdbd-*-perl packages.
 
> I'm of course willing to help (time permitting) with the implementation
> of any scheme that gets this issue fixed once we have consensus.

Thanks!


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    NP: Bruce Springsteen: Let's Be Friends (Skin to Skin)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20100412/559f043e/attachment-0001.pgp>


More information about the pkg-perl-maintainers mailing list