Hi, Am Donnerstag, den 28.05.2009, 11:14 +1000 schrieb Trent W. Buck: > I get the impression that my inability to install e.g. libghc6-zlib-dev > right now could be fixed with by bumping the version numbers in > debian/control and re-uploading, and that the ONLY reason this takes so > long is because packages are the responsibility of individual > maintainers. A particular maintainer is unavailable for a week, but I'm > not! If all it takes is a bump and an upload, I can do that right now! it is the issue now for some packages (those with versioned dependencies in the -doc packages), but in theory we have binNMU-able packages by now. This means that when packages become uninstallable, we can just request binNMUs (as kaol has done) and the buildds will fix the situation. It seems that kaol did not request a binNMUs for zlib this time, not sure if there was a reason for that. If not, then it is a matter of improving our procedure of requesting binNMUs, for example by some automatic tool that won’t forget packages. But even then there is the issue of slow auto-buildds. If we have packages A, B and C, where C depends on B and B on A, then A will be scheduled for auto-building, will wait for an upload by the buildd admin, will wait for the next mirror push (IIRC), then B will be scheduled and built, will wait for an upload by the buildd admin, will wait for the next mirror push (IIRC), then C will be scheduled and built, will wait for an upload by the buildd admin, will wait for the next mirror push (IIRC). This cannot be fast, and I think it’s not possible to schedule „package runs“ on the buildds (i.e. list packages that should be built in one run, with the results immediatelly available and all packages are uploaded in one step). This could be suggested to the buildd people, but don’t expect this to be implemented soon, if at all. The problem can be solved for one architecture by doing sourceful uploads of all packages manually. But this only helps the one architecture, others still need to wait for the buildd. Theoretically, one could play buildd and upload for example only the amd64 packages, but I recall that this is not approved by the ftp-masters (or someone else). We could ask if it’s ok for our case, though. And then there is, of course, the problem of maintainers that can (temporarily) not keep up with their work. Some packages still don’t have been built with 6.10. Arjan Oosting has given NMU permission to fix that, so if you encounter such a package, just NMU it. I encourage every maintainer of haskell packages to join http://wiki.debian.org/LowThresholdNmu I already see * Marco Túlio Gontijo e Silva * Arjan Oosting * Myself there. If all maintainers were on this list, then this would be a first step into the direction of a packaging team. Greetings, Joachim -- 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: Dies ist ein digital signierter Nachrichtenteil