I've been thinking for a while how the system should look like from a users perspective. For me it is clear that the system should not look more complicated that the decision the user made to set it up. If the user only selected half a dozen of groups and installed 20 additional packages the description of the system should not have more than those 26 items.
The second thing I am thinking about is how to replace the comps groups with something better. So here is just a random thought: What about converting them to meta packages (ok, not that new). But what about only listing the meta packages (e.g. in yum list installed). Hide all other packages. Pull them in on demand and remove them if they are no longer needed (as in --remove-leaves).
Ok, this raises to the question: Hey, what about all the packages not in a group/meta packages/whatever? How could you install those?
I have two answers for this: Some of the packages will be marked as applications - similar to the optional packages in current comps groups. May be this counts as meta package or is represented as meta packages or similar. Implementation details need still to be defined but the idea is that they look like the meta packages from the user.
For the rest of the packages I'd suggest we just create a meta package on the fly. The idea is that we do not create it for a single package but for a set of packages the user want to install for a given purpose. The meta package can though hold a brief description on why the packages got installed. May be you need a set of devel packages for a project you are working on. So you install them and give a name and a description at the command line (or use a fancy GUI tool). So yum list installed would not list the single packages but "projectfoo-devel-packages". You could probably add more packages later on or remove some. In this case the meta package would be altered or be replaced with an updated one.
What is a meta package:
May be a meta package is more or different to what meta packages have been in the past (just normal packages used to pull in other packages by requirements). I guess they have to
- Look and taste different than normal packages. Tools need to tell them from normal packages. As user should never have a chance to think it could be a normal package (Probably the biggest issue with previous meta package usages)
- be persistent. If you install them they are installed. There is no match package lists to installed packages or something. They are an "real" entity. This does not have to mean that they are real rpm packages - although this is a possible implementation.
- be the place that defines what packages are on the system and what are not. May be they need a more complicated structure. May be they need to store what of their optional requires (Suggests?) are selected by the user and what are just left out.
- be secure and easy to share. Guess they do not have files or scripts. I should be able to install a meta package/ group I just found in the internet without worrying. There might be more things needed to really make this secure. May be even disallow versioned requirements to avoid old and vunerable packages being installed.
- be easy to create, copy around and share. There need to be many of them. One oer two order of magnitude more than we have now - not counting those for the single package applications. May be they are more like recipes; come with a description how to set things up; come in several variants.