On Tue, 2006-05-09 at 00:11 -0400, Jesse Keating wrote: > On Tue, 2006-05-09 at 00:01 -0400, Greg DeKoenigsberg wrote: > > Here's the fallback position: Fernando continues to maintain the CCRMA > > kernel in his own yum repo, and *everything else* gets pulled into > > Extras > > over time. (To the best of my knowledge, none of the CCRMA apps > > *require* > > the CCRMA kernel -- it's just a huge help for getting any actual work > > done.) That way, at least Fernando has a mechanism to spread the > > workload > > for maintaining CCRMA among several assistants, and can spend most of > > his > > time maintaining his own kernel as he sees fit. > > > > Or do we fire up thoughts on Alternatives again? Somewhere that we can > host replacement packages that folks can use to assemble 'Fedora' > variants but not be tied to the kernel or whatever. If we use the same > rules, or come up with a good rule set for Alternatives, same package > quality, same build systems, etc... we should be able to call it Fedora. > Some complexity in enabling Alternatives: 1. we can't enable alternatives by default - the obsoletes it could allow would eat packages for people who really just want to use core. 2. create a sensible way of dealing with conflicts - something we don't really need to deal with right now. 3. dealing with alternative tree creation and QA. What if a user creates a fedora 'distro' using an alternatives kernel? How does that impact testing? How do we cope with the near endless number of combination or configurations we might get? -sv
