Reduced package set for Secondary arches

Josh Boyer jwboyer at gmail.com
Wed Sep 30 11:21:22 UTC 2009


On Tue, Sep 29, 2009 at 09:21:31PM -0500, Dennis Gilmore wrote:
>On Tuesday 29 September 2009 08:15:16 pm Josh Boyer wrote:
>> Hi All,
>> 
>> I'd like to ask about using a reduced package set for secondary arch ports
>>  of Fedora.
>> 
>> When this all started, we had laid down the requirements that any package
>> changes be in Fedora CVS, and the packages would all be built via the
>>  Fedora build tools.  In discussions with Dennis, it seems the current mode
>>  of operation is to require the secondary arch ports to build the full
>>  package set of Fedora (minus Exclude/ExclusiveArch) before being
>>  considered a true secondary arch.
>
>right now the only way we have to exclude things would be to commit to each 
>package an ExcludeArch line.  that in conjunction with the list of 
>ExlcudeArch/ExclusiveArch packages is how we determine what to or what not to 
>build.   i'm open to other way to implement this. but its never been on the 
>table.

Hm.  We have a slight disconnect, precipitated by my use of the word 'build'.
I have no other way to exclude things from building, nor am I really looking
to prevent people from building things.

>> Is this summary accurate?  I can understand some of the reasoning behind
>>  it. However, I find it to be excessive.  Particularly for architectures
>>  that simply would not benefit at all from having cowsay or fortune or even
>>  Gnome built for that architecture.
>
>i'm open to doing it otherwise.  a big issue was that while you may not find 
>cowsay, fortune or even gnome useful.  others do.  We don't want to exclude 

Then others can focus on getting them building and working.  Just as we have
with primary arches.  (Note, I actually use Gnome so I'd probably be working
on that anyway, but I can see how it would be superfluous on something like
a MIPS or SH port.)

>people from doing what they want with Fedora.   I will admit that it is 
>limiting you from limiting the package set and what others can do.

It's only limiting me slightly.  I can, today, create a spin with a reduced
package set and call it a Fedora Remix or the 'Fedora Blah Spin' if I have
Board approval.  This is possible regardless of arch.  However, if I were to
do that under a secondary arch umbrella it would seem to not qualify.

>> So I am requesting that we review our package set policy and try to come to
>> some agreement.
>
>Please make a proposal.

My suggestion is that the core requirement for packages built and included
in a release (defined as DVD/CD isos) are the packages that are considered
critical path.  That is actually a relatively large set of packages when
you consider that anaconda and X and various other components are contained
in that set.  I think this is more realistic as a starting point for totally
new architectures.  It also provides the foundation needed for others to
contribute and build packages on top of.

My primary concern is that we don't want to hold up a useful architecture
release because packages that are of quesitonable use don't build properly.
I'm also concerned about doing a quality release, focusing on testing the
functionality required for a viable platform.

josh


More information about the secondary mailing list