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