On Sat, May 22, 2004 at 02:43:52PM -0400, Havoc Pennington wrote: [selectively quoted throughout] > I'm calling this a canned or prepackaged configuration. I'd really like to see this. > - the package set (the only thing we can change now, via > the Workstation or Server split in the comps file for example) Actually, more than that can be changed in the install classes -- default partitioning scheme, for example. > - default settings in gconf (e.g. each canned config might > add a new config source in /etc/gconf/2/path) This could be simply which packages get installed, right? > - contents of /etc/skel And this already _is_ that. But unfortunately it can lead to confusion, if some of the relevant packages are installed before some user accounts are created and after others.... > - kernel boot options And this'd be easy to do in anaconda too. I think probably pretty easily through just the installclasses files.... > - ideally, it's dynamic instead of only install-time, i.e. > you can change a machine from config A to config B post-install. > Easier for some things than others (e.g. partitioning scheme > impossible to change post-install, config files perhaps easier, > package set relatively simple) Apt for RPM has a nice script in contrib that can add or remove package groups (as definied in the comps file). So if the config types could be definied as sets of packages, that'd be really handy. > - ideally, third parties can provide their own canned > configurations maintained separately from the main OS. > You can imagine whole open source projects that basically > just maintain a configuration. I'd like that. :) > > - ideally, these configurations can be in the installer in the > same list as Workstation vs. Server choice; it would be strange > to choose between Workstation and Server then later choose > between canned configurations Definitely. If it's not there (and I think it should be), the workstation/server/personal desktop choice should also be removed. > - ideally, local or site-specific tweaks can be kept separate from > and "override" the canned settings, so that on upgrade you > inherit new updates to the canned config This can already be done with install classes already -- <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66634>. It could maybe be made even simpler, and perhaps the comps file extended to be able to include other files (and maybe have overrides). In fact, maybe the comps file should be entirely subsumed into the install classes -- they're already very tightly linked anyway. > - Jeremy does not want to maintain this stuff in the installer Yes, that's fair -- the installer is insane enough already. But luckily, the installer has most of what's needed already done. With some basic improvements to comps/installclasses handling, all of the long-term maintenance could go elsewhere. > - selecting a given canned config has to be possible via kickstart Definitely. Leveraging the existing install classes would work nicely for that, too. > B. kickstart files. We provide a kickstart file for each > configuration, probably there's a package naming convention > like kickstart-x-terminal-client, and a convention for > where the kickstart file is installed. > > Downsides: user has to install the OS, set up a kickstart server > or make a boot disk, learn about kickstart, etc.; kickstart files > contain incidental noise such as partitioning and so forth that > will usually be unrelated to the canned config > > Upside: does not affect the installer, and again relatively > easy These sample kickstart files could be on the install disk by default, and syslinux entries created for them.... > D. config profiles usable by the installer. Same as above, but > offer them in the installer rather than just package sets > in the installer. I think this is The Way. There's already a lot more than package sets that installclasses can do. You can even hook up a post-install script. -- Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/>
