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

[Daniel Campbell]

On 01/27/2017 12:51 PM, NP-Hardass wrote:
> 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.
>
This is a fantastic idea. We need some way to handle it. Something like
ewarn/einfo to tell the user REQUIRED_USE has been triggered (and why),
but (depending on flags) then use the default or prompt for a selection.

To do this, we'd need a) a message to prompt the user with, b) a way to
convey and listen to choices, and c) a way to default to one of the
given choices in "automatic" or unattended merges.

A good portion of the information is already in the ebuilds. We have
IUSE for default flag state and REQUIRED_USE to show us which flags are
conflicting. The description for the USE flags can be gleaned from
metadata.xml or the profile's package.use.desc.

So the hard part is: how do we glue this together?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6