Rich Freeman wrote: > In general I'd avoid any requirement to use a non-base profile. > Obviously using the right arch/prefix profile makes sense as those are > fundamental config changes and they're all minimalist profiles anyway. > The issues come when you force users to use non-minimalist profiles > where we start forcing packages/decisions the users don't agree with. > (And yes, I realize the whole thread is about forcing a decision users > don't agree with - but we don't have much choice there.)
That's the point though: given that certain decisions are forced if you want to use gnome3 (ie you must use systemd, which in turn forces a whole set of decisions about all the functionality you can no longer mix and match) it makes sense to wrap those into a profile or some sort of configuration that ensures they get what they need, by default, until such time as they want to tweak things, and pick up the pieces. It's also easier for developers to handle, similar to the KDE profiles. Though I'm not sure why it's necessary to use a "non-base" profile. We have several "non-minimalist" profiles already, and the suggestion seems to fit into the existing framework well: what profiles (and sub-directories thereof) were designed for, afaict. Mixins appear to be akin to the eblit/eclass separation, and from what i've read so far most other profiles don't appear to force so many decisions, just enable what they need. However if a configuration set does require more, it would appear to be even _more_ incumbent to use a profile, not less, since it has more consequences for the end-user than simply adding a defined set of functionality that does not conflict with anything else. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
