Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

[NP-Hardass]

On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
> Forked from the gdbm/berkdb thread, wall of text ensues...
>
>
> On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>>
>> You mention REQUIRED_USE should be used sparingly, I think I see your
>> reasoning, but if so, then why did we add it in the first place?
>
> There are a few conflicting interests at play. Before REQUIRED_USE, we
> would have a bunch of checks in pkg_pretend() to test if the user's
> configuration was invalid. If it was, we could output a nice explanation
> and tell him to try again. But, bash code in pkg_pretend can't be
> understood by the package manager, and requires execution to determine
> if a package can be installed. So we got REQUIRED_USE, which fixes those
> problems, and introduces a new one: no one knows WTF to do when portage
> outputs a REQUIRED_USE error. Now you get what looks like a core dump of
> the dependency graph instead of "this package only uses one database, so
> pick either mysql or sqlite."
>
> Both approaches have another problem: USE flag constraints on packages
> simply don't work with global USE flags. Global USE flags don't work
> that well to begin with, since the same flag means different things to
> each package (and the fact that they're global means "enable foo" is all
> we get for documentation). Regardless, when you have 100 flags enabled
> globally and start installing thousands of packages with USE
> constraints, you're eventually going to get to a point where everything
> has conflicting requirements and you need to switch to package.use to
> sort it all out.
>
> Both pkg_pretend and REQUIRED_USE have that problem and try to solve it
> in different ways. If you don't care about machine-readability, then in
> pkg_pretend you could try to choose "the best" of two conflicting flags
> and just silently go with it. There are a lot of problems with that,
> like what happens if you need to add a conditional dependency on those
> flags (you can't change DEPEND in pkg_pretend). With REQUIRED_USE, you
> instead need to set IUSE defaults to get it to do something without user
> interaction, but the tricks that you can do with IUSE don't solve every
> REQUIRED_USE conflict. In the harder cases, you can try to figure out
> what to do on behalf of the user in the ebuild, but then you're right
> back to the same set of problems that you had with pkg_pretend, because
> the decision is being made in code and not in metadata/flags.
>
> I think a slow migration away from global USE flags is the only way out
> of the jam. We get better USE flag docs for free, and no REQUIRED_USE
> conflicts that the user didn't cause himself. We could probably also get
> rid of a lot of IUSE defaults that serve only to undo various profile
> defaults. It would be annoying at first, but once a few critical profile
> defaults are moved into package.use, better.
>

I might be wrong, but my suspicion is that those that advocate for
pkg_pretend over REQUIRED_USE tend to do so because of the blocking
nature of REQUIRED_USE's current implementation rather than the
construct of describing USE flag inter-dependencies itself.

So, personally, I think that we should be discussing ways of adding
interactivity to the package manager for resolution of REQUIRED_USE
conflicts rather than discussing ways to work around or remove it.  It's
a good construct, we should take advantage of it, and work to make it
more user friendly.

My initial feeling is having flags, one for interactive handling, one
for current behavior.  Interactive has two modes, like --autounmask and
--autounmask-write (and could even reuse these if possible), which does
something similar to how Debian's apt handles dependency conflicts by
calculating the alternatives and prompting the user to select a numbered
option.  So the autounmask equivalent displays the changes to the config
files and the autounmask-write equivalent writes them to the appropriate
config files.  This is just a general idea that I just came up with
right now, so I haven't put too much thought into it.  It is mostly
meant to get solutions for interactive handling discussed on the ML.

-- 
NP-Hardass