Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

[Michał Górny]

On sob, 2017-07-08 at 15:47 -0700, Daniel Campbell wrote:
> On 07/08/2017 03:29 PM, Michał Górny wrote:
> > On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote:
> > > On 07/08/2017 02:43 AM, Michał Górny wrote:
> > > > Hi, everyone.
> > > >
> > > > I think the affairs have settled enough and I've finished filling
> > > > in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> > > > the algorithms, rationale and separated reference implementation.
> > > >
> > > > If there are no major concerns raised, I will soon start working
> > > > on writing an optimized implementation for pkgcore/pkgcheck
> > > > and integrating the verification algos with the CI.
> > > >
> > > > The pre-GLEP for review is here:
> > > >
> > > > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
> > > >
> > > > TIA.
> > > >
> > >
> > > This has grown quite a bit since first recommended! Great job so far.
> > > Forgive me if I missed something, but wouldn't it be helpful to the user
> > > to let them know when automatically choosing for them? A single line in
> > > a logfile, einfo output, whatever, would be useful for people wondering
> > > how certain packages got pulled in. Users will continue to get errors if
> > > the constraints aren't met (or are wrong), but where will information go
> > > that indicates the automatic solver's choice? You and I can read an
> > > ebuild and guess from the dep spec, but what will a user look at?
> > >
> > > I searched the GLEP page for "log", "einfo", and "output" with no
> > > results. If I've missed something please let me know.
> > >
> > > Thanks for the work that's been put into this so far.
> > >
> >
> > Indeed I have entirely skipped the user output problem, and left it
> > purely for package manager's design choice. Do you really feel like we
> > need to explicitly specify it? I think it's best if package manager
> > authors decide how to best fit it into whatever output the PMs already
> > have.
> >
> >
>
> I just considered it helpful, that's all. I hadn't considered the PMS
> vs. PM devs perspective. Do we plan to support some way for users to get
> such output from Portage?
>

The original proposal suggested marking the flags with some symbol
indicating that their values were changed, and possibly even grouping
them by inferences (like 'foo => {bar}'). But I don't know if Portage
will eventually get more than the first one.

-- 
Best regards,
Michał Górny