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
signature.asc
Description: OpenPGP digital signature
