Hello World,
As many of you undoubtedly know, experimental is autobuilt these days.
Experimental is a bit of a special case in Debian's distributions,
which means that our experimental autobuilders act slightly differently
from those of unstable, stable-security, and others. Since some of those
differences are visible and important for package maintainers who are
uploading packages to the experimental distribution (that'd be you!),
here's some background information on how it all currently works.
First, before anything else, it should be understood that experimental
is built on a 'best-effort' basis. If you upload to experimental, there
is no guarantee that we'll build your package within any given time on
any or all architectures, or indeed that we'll ever even manage to build
your package. This is a conscious decision: there might be a case where
the unstable buildd network for a given architecture can't keep up at
some time in the future, which might mean that we would want to
(temporarily or permanently) move some autobuilders from the
experimental autobuilder network to the unstable one; this might result
in a backlog for experimental. Also, most of the experimental
autobuilders also happen to autobuild for other distributions, like
sarge-volatile, where the configuration prioritizes those two over
experimental, for obvious reasons. This of course doesn't mean we won't
try to build as many packages from experimental as possible; but that,
of course, is a totally different matter.
What follows is a bit of a lengthy explanation of the why of a guideline
we're going to give maintainers who want to upload to experimental; if
you're not interested in that and/or are short on time, it's safe to
skip ahead to the final three paragraphs.
Now.
As I said above, experimental is a bit of a special case; the reason I
said that is that, even if you add an URI for experimental to your
sources.list and do not use apt pinning, packages from experimental are
not installed by default if there is also a package from unstable
available. This is a good thing; experimental packages are somethong one
should use consciously, after carefully considering the consequences --
not by trying it out and then discovering that your system is breaking
down. Thus, when apt (or any of its frontends, like aptitude) is given a
command to install a package without a version number or a distribution
specified, will install the safe choice.
We've decided to not use apt pinning to override this for
build-dependencies, but to instead use packages from unstable rather
than experimental unless versioned build-dependencies tell us otherwise.
After all, if the glibc maintainers upload glibc to experimental some
day to try out some new gizmo, you don't want to have to install that
one just to try out something completely unrelated to glibc which just
happens to be in experimental.
This was not initially possible with the buildd suite, since sbuild, the
component that does the build-dependency resolving and the actual
building, checks versions only after installing dependencies. However,
buildd is free software, so we've gone ahead and patched it on our
autobuilders to verify that any packages installed are of the right
version _before_ going ahead and installing them, modifying the apt
command line to include the version number if required (which only works
if there actually is a package of the given version available -- but
that shouldn't matter for now). With this patch, apt tries to install
"package=version" rather than just "package" for packages where that is
needed. As such, packages from experimental that have a versioned
build-depends on other packages in experimental will build on our
autobuilders.
However, it will only work if the build-dependencies are fully
specified; i.e., if a package 'foo' in experimental requires another
package in experimental (let's call that one 'bar'), and another package
needs 'foo' from experimental to build, then just installing 'foo' from
experimental isn't going to cut it; you would end up with a command line
like "apt-get install foo=<experimental version>", which would try to
install the experimental version of foo with the unstable version of
bar, and fail because of unmet versioned dependencies.
The solution[1] to this problem lies in a different use of the
build-depends field: we're hereby asking maintainers who upload to
experimental, to make sure to fully specify their build-dependencies on
experimental packages; not just the packages they directly depend on,
but also the packages they indirectly, through other packages, depend
on.
Let me repeat that, because it's quite important: if you upload a
package to experimental, and you declare a versioned build-depends on
something that is also in experimental, then you *must* make sure that
you also declare a versioned build-depends on any other packages from
experimental that your direct build-dependencies depend on; otherwise,
your package *will not build*.
It is, of course, not necessary to also declare versioned build-depends
on indirectly-required packages from unstable.
There, that was it. Thanks for your attention, and now please start
using experimental for experimental packages!
[1] It might be possible to write an apt preferences file to fix this
problem differently, but not doing that actually has its advantages,
in that we force maintainers to actually know what experimental
package versions they're build-depending on.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Attachment:
signature.asc
Description: Digital signature