Jeff Spaleta wrote:
> And I'm also somewhat concerned that whatever mechanism is created to
tie in Extras into the install/upgrade proces...that mechnism needs to be general enough to encompass 3rd party repos too. No hardwiring of extras into the default logic of firstboot or anaconda. No a priori knowledge of the groupings to expect on the extra cds, things like that. Whatever works with extras needs to work with things like intranet or 3rd party addon media, in a general way...including defined package groups outside of Core comps definition.
-jef
Would the following scenario be possible? FC(n+1) is released, small Core, large Extras. Apt/yum repos go up with the new stuff. People who want to upgrade download a program (or have it installed already; the features could be added to up2date/system-config-packages/synaptic), and run it. It opens a window with various options. If they want to just upgrade to the next version, they press that button, and their rpm headers are extracted from their rpm database. This information is compared to the Extras repo, and all packages needed for upgrading to FC(n+1) are downloaded, then packed into the correct number of .iso's. They burn these .iso's, along with the Core .iso, and go along to their upgrade. The idea is that we can just use the yum/apt package managers to determine which rpm's to download, then how they should be placed on the CD's to satisfy dependencies in a simple CD1->CD2->CD3->done manner.
In addition to the 'just upgrade' option, a custom .iso feature should also be present, for clean installs on machines with different configurations than the one you're doing the downloading on. Ideally, simple and advanced paths would be available. Simple would look like anaconda's software selector, with broad groups of software. Advanced would look more like synaptic, with individual packages, with automatic dependency handling as you mark packages for inclusion on the .iso's.
Elliott Wilcoxon
