Re: testing installation bot just plain doesn't like XFree86
Santiago Vila <email@example.com> wrote:
>On Mon, 9 Apr 2001, Herbert Xu wrote:
>> If you want your packages to go into testing quickly, build against it
>> rather than unstable.
>This is not enough. I did exactly that with flex_2.5.4a-11 and
>procmail_3.15.1-3 but they are out of date by 4 days and are not being
>installed in testing yet. I assume it is because build daemons run unstable.
>We would avoid this problem if build daemons ran testing and not unstable.
Hmm, I was going to suggest that, but it's not that simple.
As far as I can tell, the testing scripts treat keeping architectures in
sync as a higher priority than keeping testing consistent. That is, the
first thing in update_output.txt is a bunch of apparently unconditional
upgrades of things that are already in testing but have only just got
built for some other architecture, after which the consistency checks
start. A couple of days ago, the uninstallability count rose by about 10
due to a number of lagged m68k uploads, for instance.
I guess this is partly a problem with lagging architectures, but it's
also going to be a problem for packages that have only just been ported;
if versions *and* dependency analysis are going to be locked across all
architectures, then we need to be more careful to make build
environments vaguely consistent across all architectures as well.
Is there any mileage in suggesting that build daemons might be able to
apply some heuristics (e.g. shlibdeps of uploaded binary packages) to
guess which build environment was originally used for a package, and
then build against the appropriate distribution? It seems that, as we
approach release, more and more people are going to want to build
against testing in order to get an urgent upload through, and build
daemons unconditionally running unstable would stymie that, just as
build daemons unconditionally running testing would stymie other things.
Manually building for all architectures may be an option, but that's
really something the buildds are there to do.
Colin Watson [firstname.lastname@example.org]