[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: build dependency alternatives sequencing

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.



"If I have trouble installing Linux, something is wrong. Very wrong."
	-- Linus Torvalds

Attachment: pgp1HyC6jq52B.pgp
Description: PGP signature

Reply to: