AllenJB wrote: > Josh Saddler wrote: >> Mart Raudsepp wrote: >>> I wanted to work at some point on splitting out gnome and kde profiles >>> to separate ones. Perhaps desktop profile could be a generic universal >>> one with USE flags enabled that rox/lxde/fluxbox and so on would like as >>> well, and then gnome adds its stuff, and kde adds its own stuff. >>> Or desktop could be one that enabled both GNOME and KDE stuff as now, by >>> multi-inheriting both gnome and kde profiles. >>> Or perhaps both a lowest common denominator desktop-base profile and a >>> big desktop one enabling everything... >> What could be nice is if users could select multiple profiles. They >> first choose the "desktop" profile, which has lots of basic stuff that's >> DE/WM-agnostic. They could then select another profile that adds e.g. >> Gnome stuff, like you suggested. >> >> I suppose the potential problem here (besides coding support for more >> than one profile) is making sure that the selected profile's USE flags >> (etc.) don't conflict with other selected profiles. Profile authors >> would have to be pretty aware of what other profiles contain, and/or the >> package manager would have to have some heavy duty resolver. >> >> One could just avoid the whole multiple-profiles-selected thing by >> cloning bits of one profile (like a minimal agnostic "desktop"), then >> adding your own USE flags, and calling it the "Gnome" profile, but this >> introduces lots of code duplication. >> > Many new users seem to have trouble grasping how profiles work in their > current, relatively simple, format. I think adding complexity to this is > only going to make things worse. > > This will also take a step back in that users will have to be exposed to > the raw profile locations within the tree. We've only just got rid of > this (as soon as the handbooks actually get updated, anyway) now that > "eselect profile" is available in stage3. Getting profile paths wrong > was, in my experience, one of the most common problems new users had.
The make.profile symlink will still be supported. It's needed at least for backward compatibility. > I believe that if you want to successfully implement this idea, you will > have to create a tool (or modify "eselect profile") to allow this to be > done without exposing users to the raw paths. Sure, we can do that. > AllenJB > -- Thanks, Zac
