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

Re: bad archive handling



Andreas Barth <aba@not.so.argh.org> writes:

> * Martin-Éric Racine (q-funk@iki.fi) [041130 11:25]:
>> That is a flaw in the way the archive is handled.  Instead of
>> accepting sources _only_ and starting the build for all
>> architectures simultaneously, the archive immediately installs
>> whichever architecture was used for the developer's build, which
>> puts all other architectures behind, until someone got around
>> signing and installing the build for each architecture manually and
>> that sometimes can take days, on less popular architectures with
>> fewer Build Masters monitoring the job.
>> 
>> In other words, the current way of uploading things ain't
>> working. Let's fix it.
>
> The problem is a bit different: E.g. gnome consists of arch-all and
> arch-any packages. Currently, as soon as the arch-all package is
> uploaded, it is installed for all architectures. The solution would be
> to install it only for the architectures where also an arch-any package
> has been installed - and you need to get wise if the package has only
> arch-all packages or not.

The changes files contains a list of architectures (+source) contained
within. If it only lists all then the packages should get installed
for all archs right away.

If it lists just some archs then there is no problem and those archs
get their debs.

If it lists all and some archs then the all should be installed in
those archs and kept in store for all other until such a time they
upload the any packages.

So far everything is simple.

However, there are a very few packages that have arch all and any
packages on some archs but only arch all on others. I don't think
there is a way to detect those except keeping an override file around.

> (However, it has mostly been solved now, as package are built from
> incoming, so if the upload does not happen to near to cron.daily time,
> it mostly works.)

Our poor m68k (and arm and many other archs for various reasons) can't
keep up with the builds that fast. The bigger packages like gnome and
kde stuff just takes longer to build even if it is started the very
minute of the upload. There is just no magic to compress a 5 day build
to finish before dinstall runs next.

Packages have been build from incoming ever since I first looked into
the buildd setup. I don't see where the "has mostly been solved now"
comes from.

Another thing not fixed is that if the new package fails to build it
could be month till a patched one is uploaded and build. All that time
the old package have a version skew.

And one more thing, after sarge we (mostly the debian-amd64 people)
plan to push in multiarch support. Which means a lot more packages are
split into any and all with strict (=) versioned depends. Every single
library upload will suffer from this problem and it must be addressed
better before multiarch can be applied widely.

> Cheers,
> Andi

MfG
        Goswin

PS: Andi, you probably know most of this but maybe not everyone else.



Reply to: