For your consideration: Secondary Architectures in Fedora

David Woodhouse dwmw2 at infradead.org
Thu May 31 14:42:20 UTC 2007


On Thu, 2007-05-31 at 15:47 +0200, Oliver Falk wrote:
> Let's break it up into possible scenarios, I hope that helps...
> 
> a) Build works fine on primary and sec archs (OK)
> b) Build works fine on primary, but fails on sec archs
>   1) Filelist wrong (trivial)
>   2) missing dep (might be trivial)
>   3) compile error (might be hard)
> c) Build fails on primary and sec arch (don't need do discuss)

Yes, it's only how we handle case (b) which is interesting here. The
rest need no discussion.

> Ad b1) * Inform the maintainer
>        * don't push to public automatically - give maintainer a
>          button to do so
> 
> Ad b2) * Inform the maintainer and the arch-team by mail
>       (* Maybe also the maintainer of the missing dep!?)
>        * push completed to public
> 
> Ad b3) * Inform the arch-team
>        * push completed to public

> I don't know if koji can provide us with the information in which step
> it failed building, but if we can use the above approach and - of course
> - - add missing scenarios (my list is maybe far away from being complete).

I had subdivided that into these four cases:

 1. A spurious build or test failure which happens on all arches
    but intermittently.
 2. A simple error introduced in the package update.
 3. Something 'hard' which the arch team need to look into.
 4. A compiler bug.

I think neither of us have a complete categorisation -- they're just
examples of the 'common' cases we can think of. But in fact it doesn't
matter. The only _important_ distinction we need is:

 b1) Something which _could_ affect all arches --> don't ship.
 b2) Trivial bug which affects secondary arch only --> maybe ship,
     but preferably just fix (depending on how much the maintainer cares
     about their package being portable).
 b3) Something 'hard' --> ship, and file ExcludeArch bug explaining it
     so that the arch team can pick it up.

I think it's very hard to make software automatically distinguish
between those cases (although your approach of subdividing further and
attempting to group them according to the appropriate response would be
the way to do it).

In practice it's also quite dependent on how conscientious the package
maintainer is. There are some who can't even be bothered to deal with
the obvious 64-bit and endianness bugs, while others are more clueful.

Even if it could easily be done, we wouldn't necessarily want to make
automatic decisions which match _either_ the lowest common denominator,
_or_ the most conscientious.

On the other hand, it's fairly easy for the package maintainer to glance
at the failing build log and decide for himself whether he cares, then
either push the 'ship anyway' button or set about fixing it, as
appropriate.

> As far as I understood. Completed primary arch packages will
> automatically be available in the buildsys itself, but not pushed to
> public... So if you commit a few packages that depend on each other, you
> will have a result quite fast on the primary archs - if everything is
> fine. If it's a trivial bug you really should be stopped (b1).

With my proposal, if you use koji's chain-build option, you should get
packages out on the fastest architecture _sooner_ than you do at the
moment. It's just that the resulting packages are only available for
direct download from koji immediately; they don't end up in the repo
until the build is 'committed', which happens when it's either completed
or been excused on all of the architectures it was running on.

> Maybe we should also clear, do we speak about *INITIAL* builds or
> changes/updates!

Not initial builds of existing packages when a new architecture is added
-- those should all be done in advance by the arch team, ready to 'seed'
the build system before the architecture is added. And any needed
ExcludeArch: should be in CVS long before the new arch comes online in
the build system.

Not really initial builds of new packages which come later, either --
those should have Exclu{de,sive}Arch set appropriately anyway because
that's part of the review guidelines. They aren't particularly
interesting -- if you build for the first time and find that it doesn't
build on some architecture, you should take a moment to look at that to
see whether it's a generic or an arch-specific issue, just as you would
with an update.

So we're really just talking about _new_ failures which happen after
changes/updates to packages which _used_ to build correctly. Of course,
those might not be due to the changes in the package itself; they might
be bugs in a dependent package or the compiler, etc. Or they might have
been latent bugs which always existed but only show up under certain
circumstances.

> Packages that once built fine, shouldn't really fail in case of an
> update/change I think... Maybe the initial and update/change thinking
> mentioned now should be also included in the above list/work-flow...
>
> I don't know if you like my above approach, but I think if we split it,
> it's easier, since we can find a good solution for each 'small problem',
> instead of talking about *one* 'huge problem'.

We're talking about changes/updates to existing packages and also
initial builds of new packages -- but the initial builds of new packages
aren't really much of an issue, so the only thing we _really_ need to
concentrate on is the changes/updates to existing packages.

So effectively we've _already_ split it up as you suggest, and there's
only one thing left to actually think about once we do that.

Not that it stops people from throwing in unrelated objections and
muddying the waters, of course :)

-- 
dwmw2




More information about the fedora-devel-list mailing list