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

build dependency alternatives sequencing

Fellow Debian folk.

Those of us who run autobuilders have started seeing more cases of a new
class of problem showing up in our buildd email that we'd like your help 

It is possible in the Build-Depends specification of a package to give
alternatives using syntax like:

        libltdl0-dev | libltdl3-dev

On the surface, this seems like a reasonable thing to use, since it offers
more choice for the person building a package.  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.

In many cases, like the one above, the problem may really be that the -dev
version of a library should always be unversioned, like libltdl-dev, with only
one version typically installable at any time for building new programs even
if multiple versions of the runtime are still around.  Sometimes this has been
handled by creating a virtual package for each alternative of a development
library to provide, but I postulate that in most cases that's not necessary.
In any case, when listing alternatives, please always list the newest and most
likely to work with sid one first!

In some cases, it may be that a package changed names or structuring between 
potato and sid, and you're trying to make it possible to build the package on 
more than one version of Debian.  That's fine, but again, please try to put
the package that will work with sid first!

There are a couple of other oddball cases, like 

        svgalibg1-dev | svgalib-dummyg1

where svgalib isn't relevant for all architectures.  And, I'm sure there are
other valid and seemingly-valid reasons for using the alternatives syntax in
a Build-Depends specification.

What I'd like to ask is that you realize that there is a "preference" implied
by the alternatives syntax, with the first alternative listed being the one 
that will be tried first (and perhaps only!) by the autobuilders.  Thus, it 
would help a lot if everyone would try to put the package most likely to allow
building on the most architectures in sid first.



Reply to: