On Mon, Sep 10, 2001 at 01:44:37PM +0900, Junichi Uekawa wrote:
> Bdale Garbee <bdale@gag.com> 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 <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
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)
Attachment:
pgpivRQOnfGDr.pgp
Description: PGP signature