Reduced package set for Secondary arches

[Dan Horák]

Dennis Gilmore píše v St 30. 09. 2009 v 08:28 -0500: 
> 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.

I have read somewhere about a man porting Fedora to a MIPS based Chinese
netbooks, but evidently behind a closed door :-( The hardware is
http://www.lemote.com/english/index.html and some resellers exist in
Europe and US.

> > 
> > >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 

Mono exists on s390/s390x and builds in Fedora/s390x.

> 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.  


Dan