Dear everyone interested,
Am Mittwoch, den 01.01.2014, 16:56 +0100 schrieb Andreas Barth:
> 16:32 < aurel32> couldn't the dependency of haskell be handled in a better way
> 16:32 < aurel32> some packages are already at the 3rd binNMU in 3 days
> 16:32 < aurel32> some packages are binNMUed the day after they are uploaded
> 16:34 < aurel32> just found one with the second binNMU in 6 hours
> 16:37 < aba> who is scheduling those?
> 16:41 < aurel32> haskell-markdown on mips finished building at 09:40 this morning
> 16:41 < aurel32> waiting for a new binNMU
> 16:41 < aba> k
> 16:42 < aurel32> pandoc on i386, finished building yesterday at 12:55 after an upload, binNMU finished to build at 02:12 this morning
> 16:42 < aurel32> haskell-glade on i386, binNMued the 30, the 31 and the 01
> 16:44 < aurel32> it looks like some dep-wait would be welcomed
I’ll happily clear it up, but better ask on d-haskell instead of
expecting us to somehow noticing such discussions (and thanks for aba
for forwarding it)
The problem, very roughly, is that new upstream versions require rebuild
of every direct dependency. Such a rebuild can (but will not
necessarily) change the ABI of the rebuilt package, require rebuilds of
its dependencies. This is reflected by dependencies of virtual packages
that contain the ABI – so far nothing new, I believe.
So when a package (say haskell-tagsoup) is uploaded, a number of package
will become uninstallable. I have a (not very good) script¹ which will
1. check the installability of all Haskell packages, and for those who
are not installable
2. check whether they are in state “Installed“ in wanna-build’s DB, and
3. generate "wb nmu" lines for these packages.
Debwaits should not be necessary: A package only has a binNMU scheduled
if it is uninstallable. So if a dependency of a package is
uninstallable, it will be in state BD-Uninstallable until that is built
first, and everything falls in place.
That said, there are two reasons I can think of that will cause lots of
binNMUs:
* Race conditions. A rebuilt package might have been uploaded and
already in state "Installed" in wanna-build, but the new package
might not have hit the archive, or the used mirror, yet.
I try to let things settle a bit before running the script again, but
the last few days have seen lots of uploads, so I was running it a
bit more often than usually.
* Unfortunate upload sequences. This is what happened yesterday:
- Jonas uploaded pandoc on Monday. Lots of things were able to build
again, some binNMUs required.
- Clint uploaded haskell-tagsoup on Tuesday. This happens to be a
dependency of pandoc, so pandoc, and some of its dependencies,
need to be rebuild.
The first point might be fixable by a better script. I think when I
wrote it, the Version column in the database did not contain the
"...+b1" version after a binNMU was done, this seems to be fixed now. So
it should be possible to detect such a race condition in the script.
The second point is harder to avoid. I think it will be better as soon
as we have DPAs (or PPAs?), as I hope we can do all haskell uploads to a
DPA first, do all the binNMUing there first on only one architecture,
and do occasional migrations of all changed packages at once into
unstable. This will reduce the Haskell binNMU load on the other
architectures, and reduce uninstallability times in unstable.
Greetings,
Joachim
¹ http://anonscm.debian.org/darcs/pkg-haskell/tools/haskell-pkg-debcheck.hs
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part