Release team (cc'd): could somebody please check that the plan below
is sane? Are you OK with going ahead?
On Tue, Apr 13, 2010 at 12:49:56AM +0300, Damyan Ivanov wrote:
> -=| Niko Tyni, Mon, Apr 12, 2010 at 09:49:56PM +0300 |=-
> > Plan B: "revert for now"
> If epochs can be avoided (by a slightly less ugly version like
> 1.610.90+is+1.609), I am all for Plan B. This will still break
> dh-make-perl, but only until the next DBI release.
I can't see why that wouldn't work (although I'd prefer
the epoch myself but never mind.)
So I propose the following updated plan (supported by Gregor and Damyan):
B1. reupload DBI-1.609 as libdbi-perl 1.610.90+is+1.609-1 that
Provides: perl-dbdabi-94
B2. binNMU libdbd-*-perl [1] again with a dep-wait on the new libdbi-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 and DBI has seen a non-development release like
1.611, upload it with
Provides: perl-dbdabi-95
Breaks: libdbd-*-perl versions older than B3.
B5. then binNMU the libdbd-*-perl packages to update them to
perl-dbdabi-95
[1] the arch:any libdbd-*-perl packages concerned are
libdbd-mysql-perl
libdbd-odbc-perl
libdbd-pg-perl
libdbd-sqlite2-perl
libdbd-sqlite3-perl
libdbd-sybase-perl
and additionally two contrib ones that probably can't be binNMUed:
libdbd-oracle-perl
libdbd-informix-perl
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
