For your consideration: Secondary Architectures in Fedora

Oliver Falk oliver at
Thu May 31 15:03:49 UTC 2007

On 05/31/2007 04:42 PM, David Woodhouse wrote:
> 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.

OK, for is possible sure, but doesn't happen quite often hopefully.

> 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).

The stages of where it failed, koji should know...

> 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.

If we want everyone to be happy, we would need preferences for this and
even then, someone would be unhappy about the defaults...

> 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.

OK. I didn't get that. The thread was quite long and I didn't read every
single mail...

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



More information about the fedora-devel-list mailing list