Le sam, 22/05/2004 Ã 14:43 -0400, Havoc Pennington a Ãcrit : > Some of the things that _might_ change across canned configurations: > > - the package set (the only thing we can change now, via > the Workstation or Server split in the comps file for example) This really should be handled via package sets (standalone groups that can be distributed in standalone xml files). We've already hashed this to death last years. Standalone package sets so one can add a "usage" to a system post-install, separate sources can maintain groups and Fedora only has to bundle the most popular ones (like themes right now). Of course being able to use a package set floppy/cd at install time would be a big plus, but the focus should be post-install roles IMHO - the strength of linux systems is every reconf does not require a full reinstall. Another important points is to be able to install several package sets concurrently - these days very few computers are dedicated to a single task (OTOH a full multipurpose system is usually overkill). > - specific parts of a config file, e.g. enabling xdmcp in gdm > - default settings in gconf (e.g. each canned config might > add a new config source in /etc/gconf/2/path) > - contents of /etc/skel > - optimum partitioning scheme > - first boot screens, e.g. asking for site-specific info to > go into the configuration > - kernel boot options This part OTOH more or less assumes a dedicated system. This is very wrong IMHO. People will want a mail+music server, or an office+graphic system, etc. If you try to create setups for all the combos you'll drown. OTOH you can have a group dedicated to the best "music" conf, another to the best "office" one and users that mix all the package sets they're interested in. Of course, that also means you can not have a single package set "owning" some config files, since a lot of them will need to be shared. Automating requirement merging is probably very hairy (even more so if you allow addition of new package set to a running system). Doing it manually is probably possible provided the conf files are semi-sane (the postfix doc with all its separate config scenarii is very good) but we all know this is not always the case :( A combinaison of howto + sample conf files set + automated test script (Ã la samba testparm, nagios...) is probably the way to go. Anyway that's just my 2 centimes, feel free to disregard it. -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
