On Mon, Apr 26, 2004 at 05:52:46PM +0200, Marc 'HE' Brockschmidt wrote:
> Wouter Verhelst <wouter@grep.be> writes:
> > Also, experimental is very likely to break, meaning, an experimental
> > buildd will require a lot more maintenance than an unstable one (not a
> > showstopper, but still an issue)
>
> OTOH, an experimental buildd doesn't need to build as many packages as
> an unstable one. Looking at the quality of most experimental packages
> (GNOME 2.6, as example) and the number of FTBFS bugs in unstable, i'd
> suspect that there is no big difference.
That's not the issue.
Maintaining a buildd machine involves keeping a chroot environment
relatively clean. Buildd is written to build as many packages in as
short time as possible. One result of this is that when a package fails
to uninstall after a build, buildd does not care; instead of trying to
run an uninstallation cycle once more, it simply leaves the state of the
chroot more or less as it is, and tries to build the next package. Best
case, we have to fix that bit rot every once in a while to ensure that
the disk does not fill up, amongst other things; worst case, the buildd
ends up with /var/lib/dpkg in a broken state[1]. There are other, similar,
issues that require manual maintenance, but I won't enumerate them all
now.
When autobuilding the experimental distribution, I'd think one would
want to install packages from experimental (otherwise there wouldn't be
much point). Since experimental is explicitely for packages that are
expected to be broken, I suspect the number of uninstallation failures
and, thus, required maintenance cycles, will be much higher; as such,
the burden on the buildd maintainer will be a lot higher than it is on
an unstable buildd maintainer.
As I said, not a showstopper, but still an issue.
[1] "broken" as in "requires manual intervention before dpkg -i will
work again".
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature