On 06/07/2016 04:59 PM, Michał Górny wrote: >> >> I'll believe this when I see it =P > > You won't because the Gentoo way is to create a shitload of hacks > instead of fixing the root issue. >
I'm not arguing for anything here, I'm just toying around with an idea for fun. What we want is a way to declare USE flag constraints within an ebuild that, 1) Runs quickly 2) Prevents a package from being installed with conflicting flags 3) Preferably has a simple grammar and doesn't require bash 4) Outputs a sensible message to the user upon conflict The error message is the one clear point that pkg_pretend holds over REQUIRED_USE. If we can make portage do something sensible when it hits a REQUIRED_USE conflict, that would be ideal. But aren't (2) and (4) the most important points? >> >> So 7 minutes for an understandable English description of the error and >> how to fix it, versus 5 minutes for line noise? There's a great story in >> The Psychology of Computer Programming that ends like this: > > Not 5 minutes. Depending on the context, Portage can complain about > REQUIRED_USE in a few seconds because it has no further point > in evaluating the depgraph. > It doesn't do this, does it? I think it waits until the end. It *could* run pkg_pretend earlier, too, but it doesn't. > >>> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend() >>> can't. >> >> What do you mean here? > > I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ), > Portage will clearly know gtk2 is the only solution. Your pkg_pretend() > will tell user to enable gtk3, then Portage will hit unsolvable deps. > Congratulations, your helpful output just resulted in even worse > output! > gtk2 is not the only solution: I could set B[gtk2] and A[gtk3] in package.use. (If gtk2 *were* the only solution, then why would you have the REQUIRED_USE in the first place? Just pass --with-gtk2.) In practice, I would set A[gtk3] in package.use, and then try to emerge it again. Portage would tell me that I needed to set B[gtk2] first, and I would do that and start over. >> See #2, but "each package" is an overestimate. Only the ones with a >> non-trivial pkg_pretend() phase would take any time. > > Have you tried it, or is it wild guess? What I'm saying is that > *pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even > a complete no-op takes a lot of time because Portage needs to do a lot > of setup to run it, and can't do multiple packages in parallel. > Of course I haven't tried it =) One of two scenarios holds, though: * if a trivial pkg_pretend() is slow, then one that checks for USE flag conflicts isn't actually that much slower. * if a trivial pkg_pretend() is fast, then only those packages that have a non-trivial pkg_pretend() make it slower. REQUIRED_USE should be faster either way, but that's currently at the expense of the error messages and I'm not sure those *can* be fixed.
