[gentoo-user] Re: confessions of a current USE=*

[»Q«]

On Fri, 15 Apr 2016 15:06:18 +0200
Alan McKinnon <alan.mckinnon@×××××.com> wrote:

> On 15/04/2016 13:15, Philip Webb wrote:

> > I'm persisting with '-*', but I've never understood profiles
> > & I've never done 'emerge world' without '-p',
> > so I've always had detailed control over what it getting installed.
> > In my home-made list of installed pkgs I note with 'USE' those
> > which have a custom flag in  package.use  & check when updating.
>
> well there is such a thing as too much control and forcing yourself to
> fiddle with low-level things more than you need to.

I liked "forcing" myself to fiddle with that stuff, for the most part.
I learned more about what was going on, and sometimes even why.  (And I
continue to maintain that people who've never run with USE="-*" greatly
overestimate the time and effort that must be put into fiddling with
things.)

> Profiles are supposed to provide a decent baseline setup for a given
> scenario or usage case. Then you fine-tweak package.use to get exactly
> what you want.

One big takeaway from my migration away from USE="-*" was that profiles
do a really good job of that.  Almost all the decisions I'd made myself
turned out to be the same decisions the profile.gods had made.  (IOW,
the sense that I had a much more customized bunch of USE flags was an
illusion.)  

> Well that's the theory. In practice profiles get confusing because
> they inherit from all many things. If there was such a thing as an
> easy to use user-defined profile method, the perceived need for
> USE="-*" might go away

I'm pretty sure the opaque nature of the profile cascades was my
biggest motivation for having USE="-* in the first place, but that was
about 15 years ago and my memory is hazy on it.  I do recall clearly
that I loved the transparency and user-control inherent in the Gentoo
way, and that being unable to understand what was happening in profiles
and why seemed counter to that.

It would be great if there were a tool to make it easy to see where in
the cascade of inheritance which constitutes a profile any given thing
is set.  Even greater if there were comments in the profiles' files
about why things are set the way they are.

> > Occasionally, a new flag trips me up, but it's fairly easy to
> > recover once the location of the problem has been determined.
> >
> > My own complaint re USE flags is the all-too-meagre output of
> > 'euses' :
> >
> >   root:502 ~> euses gtk3
> >     app-editors/bluefish:gtk3 - Enable GTK3 interface (default)
> >     app-editors/emacs:gtk3 - Prefer version 3 of the GIMP Toolkit
> > to version 2 (x11-libs/gtk+) app-editors/emacs-vcs:gtk3 - Prefer
> > version 3 of the GIMP Toolkit to version 2 (x11-libs/gtk+)

[snip]

> > This urgently needs cleaning up, like much of Emerge's output.
>
> Indeed. Most flag definitions give you MORE information when removed.
> Less junk implies more truth

Here's an example of a description I find far more useful than most of
them:

$ euses debug | grep parted
sys-block/parted:debug - Enable debugging as encouraged by upstream:
[The default configuration] includes --enable-debug (by default), which
contains many assertions. Obviously, these "waste" space, but in the
past, they have caught potentially dangerous bugs before they would
have done damage, so we think it's worth it. Also, it means we get more
bug reports ;)

Without that, I'd certainly decided to disable debug for parted.