[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Draft proposal for using full anaconda as the default Fedora download



Máirín Duffy (duffy fedoraproject org) 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]