[Mageia-discuss] Mageia Mirror size

Olivier Blin mageia at blino.org
Mon Oct 4 00:09:12 CEST 2010


Michael Scherer <misc at zarb.org> writes:

>> If we have a separate directory for noarch, it could be shared by all
>> arches, which means there would be no such unsync issue.
>
> We have 2 choices : 
> - all arch synced ( ie, x86 and x86_64 for now, likely arm and others in
> the future )
> - main archs synced, others possibly unsynced ( either the time to be
> ported, or more "permanently" ).
>
> In the past, we did it the secund way. Arm was ported from stable
> release, ppc, sparc were develop as side arch, etc.
>
> Since arm buildbots may be slower than x86 builder, using solution 1
> ( everything synced ) can cause trouble. Noarch rpm will be synced, but
> since some noarch depend on arch dependent rpms ( like python modules
> who depend on the version of python, or packages who produces
> arch-dependent and noarch rpms ), we will need to keep also binary rpm
> in sync.
> So that mean we will have to wait on the slower builder before
> uploading. Think of open office, for example. 

Right, we probably don't want to wait for slower arches to finish their
build to push i586/x86_64/src packages on the mirrors.

Having unsynced noarch packages sort of defeats the goal of noarch
packages, but well, it's probably better than waiting for arm builds on
every upload.
We could use qemu-arm to rebuild ARM packages from x86_64 build hosts
(the OBS way), but rtp would probably not be happy with that, since the
toolchain binaries are not tested on real hardware at build time.

Using cross-compilantion would be even worse, since the ARM toolchain
binaries would not even be run at build time; so you can get an ARM
toolchain package that is built fine but is never used on the official
build system, meaning you don't know if it can produce correct code, and
you can't really trust it.

Also, have unsynced ARM tree can cause some deps timing issue at build
time.

For example, one uploads a new gtk. Just after upload is finished (meaning
built on i586 + x86_64), she uploads a new gimp with a buildrequire on
this new gtk.
This gimp should be built fine on i586 + x86_64, but will not get
through on ARM because the gtk dep will probably not be available yet.


Another solution could be the way we handled x86_64 at the beginning of
its port in Mandrake. There was a iurt rebuild bot that was not
triggered at upload time, but running in a loop to rebuild packages
releases that were available on i586 but not yet on x86_64.

-- 
Olivier Blin - blino


More information about the Mageia-discuss mailing list