On Wed, Feb 06, 2013 at 12:26:58PM +0000, António Meireles wrote: > yes, a fair bit. current group structure is insane, hardly manageable, and > has too many historical baggage that does not make sense anymore. OTOH we > have now new conary functionality, some simply never used that should > simplify and smooth things a lot.
Agreed on the baggage, in a general sense. Not so sure on only two groups, just "core" and "world". > let's use enlightenment as an use case. > > we'd have, say, a enlightenment-environment package that as :source would > just have inside a enlightenment-environment.cml file something like,... > > install group-graphical > install enligtenment <insert here remaining enlightenment stack pkgs> Well, you are already past two groups here, since "group-graphical" is not one of the two groups you specified. While I do think that shipping CML for some things makes sense, I think we want more than two groups. For the sake of discussion, though, for the moment I'll assume CML for a moment. I strongly suggest binary :cml components, not :source containing .cml files. Among other things, that lets us put them in groups. To give everyone else a better sense of what you are proposing, I'd like to flesh out your example a bit. Let's pretend that your system-model file looks like this: search group-world=fl3.foresightlinux.org@fl:3/1.0-1.1 install group-core include enlightenment-environment:cml Note that enlightenment-environment is included under group-world. Then the one .cml file in the enlightment-environment:cml component would have the lines: install group-graphical install enlightenment elementary emotion ... > All this assumes, btw, as an axiom, that all future work is going to be - > end to end - system model native, which i thing is the only sane thing to > do. That I agree about. > Also, most of this approach can, and should, be automated and that is where > my metadata model (yes, i know i'm at fault here - i still need to reply, > here, to Mark's mail a few days ago and explain properly why i asked him to > write that prototype code, but that will be a way longer text than this one > ...) fits, and can get pretty handy. [in the example above we could just > produce some cml with all pkgs having, say, a given tag, or set of tags, > etc.] But you still need to build them into the groups, so there needs to be some workflow around it. Building them into the groups means that they get promoted appropriately as well as have search paths apply. > Overall this model, which plz do note is rough/too high level (devil is > always in the finer details), and still needs polish, looks way simpler to > maintain, and manage, and is overly more flexible. [and should reduce our > whole groups to a few dozen lines vs the 5k+ we have now]. If most of the system is installed by "install" lines in included CML, that's not going to improve performance. Flatter and fewer groups, however, will. I'd think that the most commonly-used groups should still be groups, but perhaps CML should be used for additional features and "overlays". Do note that CML is significantly less powerful than GroupSetRecipe. There is no equivalent in CML for TroveSet.findByName, TroveSet.findBySourceName, and Repository.latestPackages. It does not allow generalized set operations. So what makes more sense to me is that some features are CML rather than groups. What is now group-compat32 I think is simple CML, for example. But the subgroups that are used to as parts of multiple other groups really make sense as groups, not CML. So, for GNOME. I'd have group-gnome contain all the GNOME packages, group-gnome-dist be the normal environment (as it is now), and group-gnome-devel be what group-gnome-dist-devel is now. The rest, if they are needed at all, can be CML. The same for any other desktop environment: the world, the standard install, and the development environment. group-internet, group-mozilla, group-pidgin, group-printing, group-telepathy, etc. I would not have; I think that they would be TroveSets in a GroupSetRecipe used to create other groups, but I don't see any value in instantiating them separately. group-printing (while it's a little silly, why break it out anyway? But I'll use it as an example because it exists) is an example of why CML alone doesn't work: The packages required for printing are probably not entirely the same in all environments. In XFCE, you probably don't want the GNOME print queue management tools. I'd like us to go through all our current groups and for each group choose from: o Keep using the current name o Keep with a different name o Keep as CML o Keep only as metadata that drives building TroveSets for other groups o Dispose of group entirely This will require agreeing about the current purpose of the groups. There are some groups that probably never had a very well defined purpose. I would suggest that every group we keep we have a written rationale for to help us keep things consistent. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
