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
signature.asc
Description: This is a digitally signed message part
