Reduced package set for Secondary arches

[Dennis Gilmore]

On Wednesday 30 September 2009 06:21:22 am Josh Boyer wrote:
> 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.)

I have a mips desktop machine running debian and kde3   all i can say is never 
say never.

> 
> >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.
they can ExcludeArch them and move on. file a bug and get back to it when they 
get a chance/time.  by reduced set i assumed you meant only build foo 2000 
packages or some such and not even try for the rest.  if there is one or 2 
packages giving trouble then they can be excluded.  we did it with pcc64 at 
times when it was a primary arch to move things forward.

s390 s390x and sparc64 Exclude all ocaml and mono packages since there is not 
ocaml or mono on those platforms.   and yes we could probably spend alot of 
time working on making those work but they will be a thing to look at when we 
have time.  it is not a hard and fast rule that everything is built.  just 
that the tree be as close to primary arch as possible.  


Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/secondary/attachments/20090930/024ba523/attachment.bin