On Tue, Sep 11, 2001 at 09:07:20PM +0900, Junichi Uekawa wrote: > Filip Van Raemdonck <mechanix@debian.org> immo vero scripsit > > > > There are a couple of other oddball cases, like > > > > > > svgalibg1-dev | svgalib-dummyg1 > > > > > > where svgalib isn't relevant for all architectures. > > > > This is exactly one of the situations where the problem I described above > > would occur. While moving the dependencies around would probably help in > > nearly all cases [1], this would also really only be masking up the buildd > > problems. > > Note that this doesn't really mean, > "Build this source with svgalibg1-dev if this is available in > this architecture, and if not build with svgalib-dummyg1". > > > It can mean "Try to install svgalibg1-dev, but if it was not possible > to obtain it, try to install svgalib-dummyg1" No, it shouldn't mean that. > i.e. a broken mirror, or a broken package (with impossible > dependency?) can cause a "there should be SVGA support > but it doesn't in this particular build that the autobuilder has > built". > > Which obviously doesn't sound like the right meaning. Of course that's not the right meaning. The check for availability of a package shouldn't depend on the fact if the package itself is actually there, but if the package is in the Packages file. That way if the mirror is broken but it should've had svgalibg1-dev, it will bail out and not just take svgalib-dummyg1 instead. Note that if you go down the path of "this package should've been there, but it isn't installable right now so I'll just take the alternative", you could easily break packages which depend on the availability of the feature that was in a previous, correctly built version of your package. Regards, Filip -- "If I have trouble installing Linux, something is wrong. Very wrong." -- Linus Torvalds
Attachment:
pgplHyjta9Ydu.pgp
Description: PGP signature