Re: [gentoo-dev] Guidelines for IUSE defaults

[Gordon Pettey]

On Thu, Feb 2, 2017 at 12:01 PM, Rich Freeman <rich0@g.o> wrote:

> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@g.o> wrote:
> >
> > If (base == minimal), then all of the upstream defaults need to be added
> > to package.use for the upstream-defaults profile. That's bad,
>
> I'll go further and say that it is unacceptably bad.
>
> > but if
> > (base == upstream-defaults), then the important IUSE defaults need to be
> > copy/pasted from our ebuilds into the minimal profile. The latter is
> > more spiritually damning =)
> >
>
> So, I'll admit I've never been one that cared a great deal about
> minimalism so I appreciate that I may not be the best one to judge
> this, so let's go ahead and embrace your statement for the purpose of
> debate.
>
> Is there a better way we can have our cake and eat it too?  I'll admit
> that a huge package.use on the minimal profile isn't a whole lot
> better than a huge package.use on all the other profiles.
>
> Do we need another form of syntax in individual ebuilds to try to
> separate out the various cases you cite?  Does anybody care to
> actually suggest one?
>
> I still think that we shouldn't encourage users to lightly deviate
> from all the upstream defaults.  There are of course legitimate
> reasons for doing so, and you and I can probably appreciate when we
> should do this, but for somebody starting out we're giving them a lot
> of rope to hang themselves with.  It is like building a kernel
> answering no to the largest number of questions possible while still
> actually building something.  I'd actually be curious as to what that
> kernel would even be capable of doing (there are a lot of fairly
> essential things you can turn off in the kernel).
>
> In the same way, we shouldn't be too quick to deviate from upstream
> defaults ourselves (#4 in your example), beyond actual integration
> work.
>
> I'll admit the current state is a bit of a compromise, but I don't
> think we should change it unless we're changing it to something
> significantly better.  This is a pretty big-impact change.
>
> --
> Rich
>

If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
allow any granularity. Another variable USE_PROFILE should be added
analogue to DEPENDS:
IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
annoyingUpstreamDefault"
USE_PROFILE="
desktop? ( pulseaudio )
gtk? ( gtk-theme )
gnome? ( @gtk gnome-keyring)
kde? ( @qt kwallet )
qt? ( qt-theme )
upstream? ( annoyingUpstreamDefault )
"
@ is already used for sets, so "some other use_profile's set of defined
flags" seems reasonable. It should be additive only, so no +- prefixes
needed (or allowed). If a package is emerged without any USE_PROFILE set,
you might einfo "This package supports was emerged with no use profile. It
supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE
should never have any default selected by an ebuild; if a flag is required
to build, is shouldn't be a flag. You get independent behavior per package
rather than listing every single package that ever existed in
profile/package.use, package behavior actually being with the package
instead of global profiles, and you get rid of the mess of uncustomizable
IUSE="+something" everywhere that makes people like me tend to start off
every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf.
Just need to come up with sane naming convention for common possibilities
like kde, gnome, and generic desktop.

If you want upstream, USE_PROFILE="upstream". If Gentoo as an organization
wants that to be the "friendly to new user" standard, put
USE_PROFILE="upstream" in the stage3 make.conf, where those of us who want
to can simply remove or change it instead of having to nuke everything with
USE="-*". You can still use e.g. RUBY_TARGETS="+ruby21" in an ebuild if you
want a default for things that really require an at-least-one-of choice.

Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags
itself, it just sets required USE_PROFILE and lets the packages do their
thing.