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.
It would be pretty trivial to use a PORTAGE_PROFILES variable in make.conf, to replace /etc/make.profile. You could do something like this: PORTAGE_PROFILES="/usr/portage/profiles/desktop /usr/portage/profiles/gnome" You could use this approach to pull in profiles from overlays too if desired. > 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. I doubt that it will be much of an issue, but the dependency resolver will surely give you at least some kind of error if something goes wrong. > 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. Right now, users can combine multiple profiles by creating /etc/make.profile as a directory and adding as many profile paths as desired to the parent file (equivalent to the proposed PORTAGE_PROFILES approach, but using a file instead of a variable). -- Thanks, Zac
