[fedora-arm] armv7hl distro bootstrap & updates

Henrik Nordström henrik at henriknordstrom.net
Wed Sep 21 00:14:01 UTC 2011


Background for those who haven't seen the discussion on IRC. There is a
ongoing debate if the F15 effort should initially target to build F15 GA
(original release) or F15 with current updates.

Here is my views.

In the stage4 distribution bootstrap we are seeing an annoyingly high
rate of FTBFS issues where the issue is already fixed by an update, or
in f16/rawhide. The resolution to these is that we pull in the updated
srpms as needed while making sure needed changes gets into the f15
branch in git (if not already) for future updates.

The question now is if we at this stage simply should pull in all the
updates from F15, instead of continuing trying to build as close to GA
as possible.

The procssing time for building the packages is not really an issue. The
available computing power by far outweights the available resources
looking into build issues.

I am of the opinion that the current updates should be imported.

This should reduce the number of FTBFS issues and also get rid of most
chain rebuilds needed while resolving build issues by importing updates.
It may also cause some new ones, but my guess is far less than it
solves.

Trying to get the distribution built as close to a certain date is to me
a much saner startingpoint to then start rolling forward from with
updates than the current mix of GA and random fully updated packages of
much later date, and would more closely resemble the build environment
in mainline (which is always with current updates plus perhaps some
overrides, the number of current packages actually compiled to the GA
set is small)

Also, I see a risk in that we later down the road of F15 starts subtly
breaking things because updates do not get built at all in the order
intended. There is updates in F15 which need careful ordering to build
correctly, but this information is ofent not recorded in BuildRequires
and is therefore lost in the current process, resulting in undefined
outcome when later rolling forward with the rest of the updates. And no,
recording it in BuildRequires is not the right solution to this problem
for several reasons. But that is a topic for a separate mail is someone
are interested.

Also, in a general quality point of view, I see only benefits in having
as many updates as possible rolled into the release as early as
possible, and that the release which will eventually happen is as up to
date as possible minimizing security issues and other bugs.

Please note that the stage4 distribution bootstrap is unique in the
sense that it's all a scratch build without locked package release,
which means that during stage4 we can easily shake out any mishaps from
build order without having to bump package releases.


Some of the issues I worry about have already been seen where packages
have needed to be rebuilt because of other packages being updated, but
can't really tell if that's due to the updates or due to the general
state of things in stage3&4 which haven't always been the prettiest. But
that's also one of the purposes of having the stage4 step to enable
issues to get sorted out with less pain. Once we move over to koji
things will become more strict and shaking out issues takes longer time.

Regards
Henrik



More information about the arm mailing list