Re: build dependency alternatives sequencing

[Filip Van Raemdonck]

On Tue, Sep 11, 2001 at 09:07:20PM +0900, Junichi Uekawa wrote:
> Filip Van Raemdonck <[EMAIL PROTECTED]> 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


pgpK6PZwMbAJq.pgp
Description: PGP signature

Re: build dependency alternatives sequencing

[Junichi Uekawa]

Filip Van Raemdonck <[EMAIL PROTECTED]> 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"

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.



regards,
junichi


-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: build dependency alternatives sequencing

[Filip Van Raemdonck]

Hello,

On Sun, Sep 09, 2001 at 11:16:50AM -0600, Bdale Garbee wrote:
> 
> However, the sbuild tool that
> most Debian autobuilders are using will only try the first alternative without
> manual intervention.  The tool probably can and should be augmented to handle
> the full Build-Depends syntax, but while doing so would increase our build
> percentages slightly, it would also mask what may be some underlying problems.

While I agree with the masking problems comment, there's at least one
situation where it really should be enhanced IMHO. That's the case where the
dependency it picks (the first one, in the current situation) simply is not
available. I don't think there's any reasonable excuse for bailing out in
that situation.

> 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.


Regards,

Filip

[1] only exception I can think of is someone who maintains a package that
can use svgalib and who doesn't have access to i386 easily to build
himself - and granted, that's not very likely a case to happen.

-- 
War does not prove who is right, it proves who is left.


pgpBkfPPLGuV2.pgp
Description: PGP signature

Re: build dependency alternatives sequencing

[Anthony Towns]

On Mon, Sep 10, 2001 at 01:44:37PM +0900, Junichi Uekawa wrote:
> Bdale Garbee <[EMAIL PROTECTED]> immo vero scripsit
> > It is possible in the Build-Depends specification of a package to give
> > alternatives using syntax like:
> > libltdl0-dev | libltdl3-dev
> I am starting to believe that an "|" in builld depends is evil.
> When something is really required for specific arches, 
> it should have the [machine-type] thing.
> And when "alternatives" exist, we don't really know for sure which 
> version of the library things are built against, or with.

That statement is a little ambiguous.

From one perspective, clearly "we" (the entire Debian community) always
know which one's the right one to use, it's just that in various instances
it may be the porter, the package maintainer, or the maintainer of the
package being depended upon that actually knows.

The real question is who should be deciding which alternative to use
when more than one work.

In some circumstances, it's quite obvious which alternative to use;
for example roxen Build-Depends on 'libgmp2-dev | libgmp3-dev', so for
architectures where libgmp2-dev isn't available, clearly libgmp3-dev
should be used. And it seems much more reasonable to expect porters to
know which of these packages is available on their architecture than
to expect the roxen maintainer to know the status of libgmp[23] on all
architectures. The build daemons at present don't work this way, though.

In other cases, it doesn't matter to the package which alternative
is used, but it does to the autobuilder. A recent case of this was
Build-Dependencies on mail-transport-agent. Most autobuilders translate
this to a dependency on "ssmtp" which is a very simple MTA, but those
that didn't/don't would default to exim, which had an interactive postinst
and wouldn't automatically install.

Another case, which isn't quite so easy, is things like dependencies on
"libapt-pkg-dev", which'll result in a different Depends: line depending
on which version of libapt-pkg-dev you use to satisfy the dependency. If
the autobuilder happens to use an old version, then the newly build
package won't work with the updated apt at all. gnome-apt on i386/powerpc
and stormpkg on powerpc suffer from this in unstable atm.

OTOH, there are cases where upstream supports different ways of
building the package, but Debian only wants to use one of these. So
while the package might build completely successfully without, say,
svgalib available, it'll be less featureful than we might want. In this
circumstance, we'd want all the autobuilders to install svgalib when
building, but it'd be nice if we could easily indicate to users that
they can recompile the package without svgalib if they might want.

Much of this stuff really needs to be fixed on the buildd side of
things rather than by having maintainers restrict their Build-Deps,
IMO. Especially considering there are are some obvious bugs in the
buildd's current handling of things.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpKvDrBXc3Fd.pgp
Description: PGP signature

Re: build dependency alternatives sequencing

[Junichi Uekawa]

Bdale Garbee <[EMAIL PROTECTED]> immo vero scripsit

> It is possible in the Build-Depends specification of a package to give
> alternatives using syntax like:
> 
> libltdl0-dev | libltdl3-dev

I am starting to believe that an "|" in builld depends is evil.
When something is really required for specific arches, 
it should have the [machine-type] thing.

And when "alternatives" exist, we don't really know for sure which 
version of the library things are built against, or with.

For example, build-depending on " byacc | bison " might
seem reasonable, but it's not. You don't know which version
of something caused certain bug, and it is not possible 
to reliably rebulid from source.


Anyway, this is my thought, while playing with pbuilder.
I would recommend D-Ds to trying to build a package with
pbuilder, and see if the "build-depends" line confuses 
pbuider. 



regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer