On Mon, Nov 12, 2012 at 04:24:56PM -0500, Michael Gilbert wrote: > On Mon, Nov 12, 2012 at 4:12 PM, gregor herrmann <gre...@debian.org> wrote: > > On Mon, 12 Nov 2012 15:46:13 -0500, Michael Gilbert wrote:
> >> > And I'm also not sure that your NMU for libimager-qrcode-perl is > >> > correct; if I understand this correctly, it doesn't need any specific > >> > version of Imager, but just the same at buildtime and runtime, so a > >> > simple binNMU should be enough to fix the current bug. - Of course > >> > that's not a long term solution. > >> I don't think that will satisfy the release team. They want mixed > >> systems and partial upgrades to always work. I believe this hard requirement only concerns partial upgrades from stable, not from old superseded versions in testing. But I'm not a release manager and I don't think I've ever seen this rule explicitly codified. > Think about it this way: without versioned depends, there is nothing > to resolve the brokenness for users with squeeeze's libimager-perl > 0.75-1 that have somehow installed libimager-qrcode-perl 0.0333-1. FWIW, that isn't really possible as there's a major version upgrade of perl itself between squeeze and wheezy. The squeeze version of libimager-perl depends on perlapi-5.10.1, while the wheezy version of libimager-qrcode-perl depends on perlapi-5.14.2, and those aren't coinstallable. My humble opinion is that binNMUing libimager-qrcode-perl (with proper dep-waits) would be the minimal action too solve the RC part of this issue, as the sid and wheezy versions of libimager-perl have the same IMAGER_API_VERSION. No Breaks or versioned Build-Depends are needed for working upgrades from squeeze AFAICS. If that course of action is chosen, it would be advisable to freeze libimager-perl in sid until the release, to ensure that any future builds of libimager-qrcode-perl don't get accidentally compiled with a wrong IMAGER_API_VERSION. If we want protection for upgrades from wheezy/sid, the next smallest fix would need AFAICS - a sourceful upload of libimager-qrcode-perl 0.033-2 that Depends and Build-Depends on libimager-perl (>= 0.90+dfsg) or something like that - a tpu upload of libimager-perl 0.91+dfsg-3 that Breaks libimager-qrcode-perl (<< 0.033-2) The tpu upload could be avoided by reverting libimager-perl to 0.91+dfsg in sid, either with an epoch or a mangled version number (0.93+dfsg+is+0.91+dfsg or whatever.) In any case, after the release, I think a proper dependency system should be implemented like in the libdbi-perl case, and appropriate Breaks should be added against the wheezy versions. If there are no thinkos above (somebody please check it :), I think it's the release team that should make the call. -- 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
