Greg DeKoenigsberg (gdk@xxxxxxxxxx) said: > > - seamlessly allow Extras to be everywhere that Core is from an > > installation path - anaconda, yum, pup, system-config-packages, etc. > > > > This is done for yum and pup, but not yet for the others. > > But we're working on it, right? I mean, this *is* the future, right? Yes. However, in the case of system-config-packages, this gets messy - if you're spinning various CD groups of Extras, how does it know about these CDs to know what you need? Do you duplicate any CD-related metadata in internet-connect repository data? Do you have it scan CDs for options of what to install? Something else? > > - Extras and Core have differing release models, generally. Core > > has a Release, plus Updates. Extras has a more rolling release > > model. > > I'm not sure how true this actually is. It's only sorta rolling; we did > end up rebuilding the Extras world right before FC4 came out, and I > suspect we'll do the same for FC5. Well, packages are much more likely to be added in Extras then in Core post release - someone will import something new for all the FC releases currently in play. Packages very very rarely get added to Core in updates. There's also Seth's favorite - multilib. :) > > - With the more rolling release model of Extras, how does that fit > > in with building CD images, or grouping of packages? Do we > > offer services that build Extras CDs on-the-fly? Do we have > > generated Extras isos at Core release time, and never afterwards? > > Do we allow third-parties to make their own Extras isos with > > scripts (or infrastructure) that we provide? (Cue the Trademark > > policy!) > > My take: we figure out favorite collections and build ISOs for each of > them. Making sure they all "work" in conjunction with Core could be > tricky -- but we could perhaps ask prominent community folks to "release > manage" their favorite collections. In the long term, we allow anyone to > create their own collections as well, perhaps using the tools and rules > that we end up developing to maintain the favorite collections. The problem I see is we need the trademark ducks in a row before we can do much of this, as it was a barrier to Extras CDs in the past. Perhaps I'm missing something important that changed this. > > - Support for languages not deemed as being fully supported (whether > > by average translation percentage, or some other metric) would > > exist solely in Extras. > > > > Frankly, I think this is a bad idea, but I know that others > > disagree with me. > > Why do you think it's a bad idea? If you don't have support for your language at install time, how do you read the screen to install it later? :) More seriously, I think this needs to at least block on anaconda/etc. installing from secondary repositories, as it's something that *would* be wanted at install time in most cases. > > I suspect we could come up with some significant reducutions in > > Core if we tried hard. Looking over a report of all the leaf nodes > > in the distribution would produce lists of smaller packages that > > could be removed... > > Any chance we could automatically generate for every Core release the RPM > dependency graph that Adrian Likins used to build? That would be a > *perfect* mechanism to respond to the "hey, let's just remove package X" > arguments. Lack of space for 50x50 page postscript documents? > > Comments? Flames? Not at all what you were looking for? > > One more thing: What about "Fedora Commons" instead of "Fedora Extras"? I > realize that it then overloads the FC acronym, but "Extras" seems wrong to > me now, especially since we're going to be relying so much upon Extras > over time. Contrib! *ducks* Would Commons get confused with a patent commons? Bill
