On Sun, Feb 15, 2004 at 10:24:09PM +0100, Goswin von Brederlow wrote: > Wouter Verhelst <wouter@grep.be> writes: > > Op za 14-02-2004, om 11:33 schreef Goswin von Brederlow: > > > He is partly right complaining about failing packages that fail due to > > > an RC bug in the toolchain (or not yet compiled packags). Its partly a > > > problem in the buildd/wanna-build implementation and the buildd admins > > > job to keep an eye on. In the case of build-essential packages a > > > Dep-Wait will also not work right since sbuild does not update > > > installed packages unless the source needs it. > > > > You're completely missing the ball here. Build-depends and > > build-conflicts have been invented exactly to fight this kind of thing. > > If you have a problem with some part of the toolchain, adding the right > > build-depends and/or build-conflicts is the right thing to do; when > > sbuild (buildd's building component) sees that the build-depends and/or > > build-conflicts are not satisfied by packages that are installed in the > > chroot right now, it will generally do the right thing, i.e., update the > > package in question. > > If it happens for all archs sure. No, if it happened already it's too late. By the time Christopher uploaded those KDE packages, he *knew* they would fail with a certain versions of the toolchain. You know, that's what we invented build-depends/conflicts for. > But I would hate anyone who uploads a new mozilla or galeon because > one unstable version of gcc on say alpha has an RC bug preventing it > from getting build. Yeah, me too, which is why I didn't suggest it. [...] > So lets clear this up so I don't do something wrong if I ever becaome > DD and take over the buildd admin job. Last time I saw this hapening > here I asked on #debian-devel because I wasn't sure and got told (by > some maintainers, not buildd admins) that such arch special temporary > problems should not be added to the Build-Depends/Conflicts. Was that > wrong? No, it wasn't. But you're also right that there's no reason to do a new upload just for a single bad toolchain version that hit you. If you know, before uploading your package, that there's a certain compiler (or some other part of your build-dependencies) that *will* fail to build your package correctly, then you add that to your build-conflicts. > Or would a patch be added to source-dependencies-unstable for > the duration of the build for that? No, those are add-only IIUC. [...] > > Again, that's superfluous. This is what "failed" and the "Should I > > build?" mails are for. Every time I get a "Should I build?" mail, I > > check why the package failed previously, and if the message listed in > > wanna-build contains a bug number, I'll check whether that bug is still > > open. Of course, that only works on machines that do have access to > > wanna-build, which is probably why you didn't see those mails yet... > > > > There's no real reason to implement your suggestion... > > The waiting for a bug would be to get packages rebuild, which is what > was the problem in the mail. You only get the "Should I build?" mail > on the next upload. If the bug is against another package there is no > reason for another upload, so you won't get the mail. Ah, that's what you mean; I thought you meant waiting on the closure of a bug in the package being built. I'm not sure what you're suggesting is useful then, but don't let that stop you :) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Attachment:
signature.asc
Description: Digital signature