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]> <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)
pgpKvDrBXc3Fd.pgp
Description: PGP signature
