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
