On Fri, 27 Jan 2017 15:51:27 -0500 NP-Hardass <np-hard...@gentoo.org> 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. If I may add a user opinion. I agree with you but I would choose different solution for user-friendliness. Instead of _adding_ interactivity to PM I would _remove_ it. So if there would be multiple choices the user would not be prompted, but some default option would be selected by PM. To the user, such behaviour would be similar to current handling of virtuals - if a package depends on a virtual the user is not prompted to make a choice but the default is selected instead. Some of the USE settings levels would have to be overridable by PM in order to achieve this - most likely it would be global and default ones and perhaps also the ones in make.conf. The override of a particular USE flag would be valid only while there is a need. Technically, PM would not update any configuration files (in /etc/) in this process. The required information would be stored in PM's internal structures (/var/db/pkg?). In general, I consider user friendly behaviour if emerge does not ask me anything during the update/install process. It however should clearly show me what it is going to do (with --verbose enabled). Best regards, Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
