comments inline, bellow António Meireles -- The Foresight Linux Project http://www.foresightlinux.org
On Wed, Feb 6, 2013 at 11:44 AM, Michael K. Johnson <[email protected]>wrote: > On Wed, Feb 06, 2013 at 08:40:55AM +0100, Tomas Forsman wrote: > (...) > António, have you put thought yet into which groups that we currently > have are really vestigial and should not be preserved in FL3? > > 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. To me the basic groups we 'll ship should just fit two main, and complementary, purposes - one - provide basic/minimal sets of (well defined) functionality, on top of which higher level stuff will run. Here, on this regard, i can think of 'just' two groups - group-core (or -bootable, or something in same lines) which would be the minimal set of stuff expected for an OS instance to boot/run (obviously in text mode), and a another one, with the minimal set of stuff neded to run graphical (Xorg, these days) environments. On the other extreme a big, wide, closure/-world group to be used for dep resolution purposes. All else in the middle, and that is currently in the groups, is probably more manageable, by taking advantage of the :cml machinery that mkj and erik placed in conary, just before they left rPath, but that was never, ever, put to proper use. (man conary and search there for CML). this would give us, something similar to what yum does on top of rpm repos in a way insanelly more powerfull and deterministic. 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> and the user would just do a conary update enlightenment-environment and things would just work. [plz do note that there are no labels/searchPaths above. all packages referenced would be in -world/closure group, so that dependencies would be handled from the start, etc.] 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. 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.] 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]. All the best, António _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
