http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures

[Oliver Falk]

Hi Manas!

On 07/11/2007 07:15 AM, Manas Saksena wrote:
> Tom "spot" Callaway wrote:
>> On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote:
>>
>>> How are Secondary arch releases suppose to go about getting official
>>> "Fedora" status?
>>
>> The secondary arch team exists, has a working koji buildsystem, is
>> okayed by FESCo, and has packages (and or trees) ready by either the
>> main Fedora timeline or a reasonable timeline defined by the secondary
>> arch team.
> 
> A couple of additional questions on that front...
> 
> First, I assume that secondary arches can have a subset of packages
> from the main Fedora release. It might be a good idea to specifically
> say that. I dont know how to quantify it, but it also probably needs
> to be a reasonably large subset for it to make sense.

No subset. Koji will start every build on primary and secondary archs.
If it's a package that only works on i386 (eg. lilo), then it will have
an ExclusiveArch and therefor will not be built on SecArch. If it's
something like openoffice that doesn't work yet on some SecArch, there
must be an ExcludeArch in the spec.

> Second, can secondary architectures go beyond the primary architectures
> in terms of feature support? For e.g., can a secondary architecture
> include a cross-compiler toolchain?

Only if you do the usual package review process and it lands on fp.o CVS.

> Along the same lines, can secondary architectures have modified spec
> files that go beyond fixing build/run-time issues. For e.g., can a
> secondary architecture take a large package and further split it into
> more granular subsets for the purpose of better footprint control.

No. Everything that is built, uis checked-out via CVS from fp.o CVS. If
you want to modify a spec, you need to talk with the package maintainer...

> Essentially, these are real things that would be relevant for "embedded"
> architectures (like ARM). And, what I am trying to get to is what would
> make sense within the context of Fedora, and what may be features that
> need to be added in a derived from Fedora (but not Fedora) distribution.

SecArch is just like ppc(64) and s390(x), everything get's built. If
something breaks, ArchTeam needs to take care of. If something will
never work on the SecArch because it's unfixable, you need to
ExcludeArch it in the spec.


Spot:
Well, maybe we should think about the 'subset question'. It might make
sense to exclude packages that *would* compile find on a SecArch, but
doesn't make sense at all to have it on that arch. :-)

-of