(Note: I only lurk on anaconda-workers, if you really want to make sure I see something here, cc'ing me or taking the discussion to anaconda-devel-list is the best plan) On Mon, 2004-05-10 at 17:25 -0500, Jeff Licquia wrote: > Dario Rapisardi wrote: > > Perhaps it would be better to extend the > > comps.xml format. For example something like this: Extending comps to contain information about things other than package groups is fairly ugly. I'd rather add a different metadata xml file with a separate DTD than overload comps.xml. > > This way no one should have to hack in the installclassess directory. > > And in case the <installclasses> tags are missing, use the sensible > > defaults for the default classes. > > Could this be feasible? > > We can support this now, with only a minor change to the code. > > Suppose we changed the group layout so that install class "Workstation" > included only the group "workstation", "Server" included "server", and > so on. Then, the groups themselves would contain other groups. New > install classes would be encouraged to do the same thing. > > Since all this is done in comps.xml, no code changes are needed to > switch the definition of "Workstation" to use vim instead of emacs, say. This would work (in fact, it's how things were in days long past), but it feels slightly hacky. You still have to make sure your install classes match your comps file and don't really gain all that much over the current state of things, IMHO. > The one disadvantage: forking from upstream, which I'm trying to keep to > a minimum. Perhaps Jeremy has a perspective on all of this. I'm not against the idea of adding another file to describe install classes. In a prior life, it was something that I was interested in making more easily done. And there is some degree of that now, it's just thinking about the problem from a different angle. Instead of using some other file to describe the install classes, there is the ability to completely override the given install classes in the product.img file. If you have an installclasses directory there, it overrides the contents of /usr/lib/anaconda/installclasses. This gets used in Red Hat Enterprise Linux so that each of the AS, ES and WS variations can use the exact same installer (stage2.img) but provide different install classes. This works for my current needs as well as the needs of some other consumers of anaconda that I know of, but others may have different opinions. Somewhat thinking aloud along the line of having the install classes described by some other data file and ignoring the implementation detail of the fact that kickstart and upgrade are technically install classes, the following things would need to be handled by any other representation of the information * Name, with translations * Image pixmap to be used (could go with basing off of some sort of id as is done for the pixmaps with comps groups) * Description, with translations * Descriptive text field used for describing the packages selected by default with the install class. This is used in the desktopchoice step * Some sort of sort ordering (could do similar to how this is done for comps as well) * Some way of handling steps which should be shown or skipped by default. This is done a little bit less now, but still nice so that people doing, eg, a desktop install don't have to see the scary disk druid screen by default * Comps groups to select by default * Some information about what to do about partitioning Things currently used but not needing to be carried forward * showLoginChoice - If you do a graphical install, you get a graphical login by default. I'm probably going to be making things so that if you end up in a text mode install, you end up with text mode by default as well. This makes sense as choosing to do a text install is less than useful; if you have to do one, then chances are X doesn't work and it won't work post-install either Unfortunately, I do know of places that use some of the overriding ability to pre-configure some other things as part of their install process and going to install classes being completely data as opposed to a bit of python loses some of that. I'm not against considering it, especially if there are suggestions on how to maintain that degree of customization. I don't want to go to some hybrid half/half solution, though -- that just strikes me as another way for people to screw things up and create disaster. Thoughts? Jeremy Jeremy
