Hi Bill, 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? If the use case is, I'm upgrading from F13 to F14 with a fresh install but I don't want to have to sit around for 2-3 hours trying to cherry-pick the add-on packages I installed last time... there's probably a better way to solve it than checkboxes in anaconda's GUI right? Is there a different use case those package-by-package checkboxes solve? (Noting that if you really need to spit out a bunch of systems with a particular manifest of packages you're better off using kickstart and skipping the GUI?) > Another idea would be to make all the groups we have either much more > general (the desktop group would include its sound apps, the KDE group > would include its sound apps, and we could drop the general group), or > much more focused (specific task groups, like 'office-suite', or > 'imap server', or similar). We could then build up logical installation > classes or installation profiles that consist of combinations of these. > (This is what another product does, of course.) > > > > This is a big advantage of the live media; it's not just curated for the > > > default offering, but gives a good method for any use case to design for > > > its offering. > > > > This is also a huge problem with the live media.... it proliferates the > > limiting notion that Fedora is a bucket o' packages rather than a > > platform to build upon. > > 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. Also thank you for the 'theoretically' (she says after the experience of discovering the design suite spin had no networking stack for some weeks) > > > Stepping back for a sec, a lot of this would go back to actually designating > > > what the non-Live media is for. We've *never* done that, leading to it > > > essentially just being 'a set reasonably comparable to what was on the old > > > Red Hat Linux CD/DVD.' I don't see how something with that mantra helps > > > with our usage cases/target audience, regardless of technical benefits. > > > > Which do you mean? The mantra that designating what non-live media is > > for doesn't help, or the mantra that the DVD is comparable to ye olde > > RHL doesn't help? > > The latter. The non-live media has never had a real target other than the > bucket'o'packages idea, and therefore isn't really designed for anything > specific. It'd be nice to fix that wouldn't it? ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
