Re: dpkg upload 1.15.8.2
Hi!
On Sun, 2010-08-01 at 13:48:54 +0200, Philipp Kern wrote:
> next time, when uploading a piece as critical as dpkg, please look at the
> archive state before uploading. dpkg 1.15.8.2 had so strict dependencies
> that it could not be built anymore (due to debhelper, dpkg-dev and
> libdpkg-perl I think), as the dpkg version on mips was still 1.15.7.2.
> (Newer source uploads also auto-trashed the builds on buildds.) A quick
> glance at rmadison would've told you that.
Actually, the strict dependencies introduced in 1.15.8.2 should have
been there in 1.15.8, so the fact they were missing was just a bug
(and a helpful one, or all the architectures would have suffered the
same fate :).
I don't see why it cannot be built anymore, the only thing changed was
bumping a dpkg-dev Depends on dpkg, at which point the new dpkg-dev
(arch:all) became uninstallable because the new dpkg (arch:any) was not
yet available, *but* those are always installed on buildds.
Now that you've brought this up, I've recalled last time this happened
(2007-12, dpkg 1.14.14) it was deemed a problem in wanna-build's
AutoDepWait support. This was discussed in oftc.net on #debian-release
back then.
If I had remembered this would cause problems again I'd have checked,
so I think it's a bit unfair blaming us (well me as the one doing the
change and the upload :) when this seems like a bug in a piece of the
build infrstructure.
(BTW I'd be curious to know what the source auto-trash thingy means.)
> So I had to build 1.15.8.2 against testing after the whole of unstable got
> moved to bd-uninstallable, that's also why the binNMU happened on mips.
Regardless of the above, I'm sorry this caused you guys major
inconveniences. A positive outcome though, is that a bug was unvelied.
I'll be uploading .3 tomorrow, just in case anything else pops up.
regards,
guillem
Reply to: