Fedora Extras Development Build Report

[David Woodhouse]

On Sun, 2005-05-08 at 12:04 +0200, Ralf Corsepius wrote:
> It's how I understood your proposal and how Seth seems to have
> implemented the FE build system: ATM, one build failure on one of i386,
> x86_64 or ppc prevents building a package for the other architectures
> and therefore disqualifies a package from being upgraded.

We need to distinguish between a build failure which is observed by the
build system, and the deliberate exclusion of a given architecture by
use of ExcludeArch: in the spec file.

The former _should_ be treated as an error and should prevent the
package build from completing successfully. That's what you seem to be
referring to above, and it's a good thing.

The latter is OK, but should be used with care, and a bug should be
filed in all cases when an ExcludeArch: is used.

If a package fails to build, the package maintainer is expected to
investigate the failure and determine the cause of the problem. If it's
something which is actually arch-specific and repeatable, like a
compiler bug, then the maintainer is free to add an ExcludeArch: for the
offending architecture, with a comment referencing the bug which is
preventing the build from working. Then the build can be retried, and
should complete successfully.

If the problem is within the package itself, the maintainer is expected
to fix the problem as soon as possible -- that's what maintainers are
for, after all. If the maintainer doesn't have time to fix the problem
immediately, a bug should be filed explaining the problem and _perhaps_
an ExcludeArch: could be added in the meantime.

> In practice, developers will only have access to a limited set of
> architectures, in some cases developers do not/do not want to support
> some architectures, so ... there will always be "second class citizen
> packages" on some architectures ... 

I'm not sure who you're referring to when you say 'developers'.

If you mean the upstream developers of the code in question, then it
sounds like the package should never have been imported -- we should
require sane, portable code in packages built for Extras.

If you mean that the maintainer of the Extras package can't be bothered
to do their job properly, then a more suitable maintainer can be found
or the package dropped.

-- 
dwmw2