Máirín Duffy (duffy@xxxxxxxxxxxxxxxxx) said: > On Mon, 2011-01-24 at 22:29 +0000, Bill Nottingham wrote: > > My engineering mind immediately goes to 'how would we implement this in > > terms of the existing infrastructure of the comps file, kickstart files, > > etc.', and is somewhat confused. We could have a lot of new groups, I > > guess, that are structured in this way, but it means a lot of random > > packages would no longer be selectable via the UI. This could be both > > good and bad. > > Well... regarding random packages not being selectable in the anaconda > UI - is that really a problem? Isn't it better (and I know it's not > there yet :) ) to have one place that's really optimized for package > picking - packagekit - and if users really want a particular set of > packages they can do post-install? It makes sense, yes. I'm just trying to organize what we currently have, where the package groups (and the attributes around the packages - mandatory, optional, etc.) are exposed as installable entities: - in anaconda, in this group selection screen - in anaconda/kickstart, in %packages - in yum, post-install - in PackageKit, post-install So, changing what anaconda does in group selection to do something else (or removing group selection entirely), without changing where it's exposed elsewhere doesn't help us as much. Now, if it just means we expose the groups solely as groups (i.e., no individual package selection in them), then we don't need as much drastic surgery. Although, I do wonder if the same interface makes sense for all the logical groups we have - for example, a desktop environment should likely be a single group that is installed and removed as a unit, but I could see the Games group as something that's better served by a browsing interface. > > Hm. Maybe it's me, but I think the current incarnation of the non-live > > media (need a better nomenclature) reinforces this even worse, actually > > giving the user a pile of options to select & deselect and break themselves > > with. At least with the various live media, we get something that > > theoretically has been curated and tested as a unit. > > Ah totally agreed. I wasn't really clear what I meant, sorry; what I > mean is that the spins work off of the everything bucket-o-packages and > kind of start with a clean slate every time, rather than Fedora having a > defined, familiar platform for end-users that you build the spins on top > of. (Does that make sense?) I guess you could say it is a platform wrt > how spins work today, but it's a very low-level platform that doesn't > include a desktop and some of the bits under the desktop. Tossing out ideas - if we really want a defined platform, then why not build at compose time an image of that platform, embed it on the media, install it via the live method, and then reboot into that platform to install packages/groups on top of it to customize? Obviously this complicates the installer, and if the RPM installation is as repeatable as it should be, it may not be worth the effort to optimize it in this way. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
