On Wed, Mar 31, 2010 at 08:56:28PM +0100, Ciaran McCreesh wrote: > On Wed, 31 Mar 2010 12:46:26 -0700 > Brian Harring <ferri...@gmail.com> wrote: > > Actual name I don't hugely care about, I'm more interested in > > ensuring we don't rule out doing use cycle breaking via a bad design > > decision. > > Cycle breaking requires explicit instructions from the ebuilds in > question (many of which are system things, which further complicates it) > along with support from Portage, so it's a distant future, lot of work > thing.
Nonsense. Note I said 'use cycle', not the generic 'cycle breaking'. USE induced cycles don't require explicit instructions from the ebuild at all- the PM itself can search the solution space (toggling flags as needed) to search out a way around the cycle. Consider user configuration w/ USE=X, pkg_a w/ DEPEND "X? ( pkg_b )", pkg_b w/ DEPEND "pkg_a". To be clear, you're claiming that the ebuild itself (and only the ebuild) is the the one able to state- emerge pkg_a[-X] emerge pkg_a[X] As demonstrated, that cycle is easily broken. A lot of the cycles users run into originate that way also. Reiterating a point you're missing also, any use cycle a user hits is currently requires the *user* to sort it out anyways- what VALID_USE adds is the ability for the package manager to do it itself. As for the "portage is developmentally slow" contribute frankly- per the norm w/ open source, you want something, ultimately you're the one responsible for the work. Less contentious answer, I've already gotten an estimate of 2 weeks out of Luther (the person who has been knocking out EAPI4 features in the last month or so)- I'm not that concerned about it. Actual work is a few days, motivation per the norm is the main time sink. > Since we need pkg_pretend to cover all the things that aren't use flag > related anyway, it makes sense to just go with that rather than > delaying things even further. And as I've already laid out in the bug, pkg_pretend has it's own set of issues when compared to pkg_setup due to it being non temporal, thus having high false positive potentials. The main council push for pkg_pretend was to move use constraint checking to pre build. VALID_USE does that cleaner and enabling use cycle breaking to be built; as such I'm pushing it up to them unless someone can find significant *real* flaws. Soo... as I've described on the bug and here (repeatedly), exempting 5-10 cases from the tree, what pkg_pretend enables can either be done better via VALID_USE, or is a degradation due to temporal concerns when you move the code out of pkg_setup. Short version: it's a step backwards. > When in the distant future Portage > becomes able to deal with cycle breaking, ebuilds can be converted to > use something like VALID_USE when they're also updated to export > information on which of their flags can safely be toggled. You're being short sighted. VALID_USE is useful now for representing use states that are allowed; that data itself is useful for use cycle breaking. Added bonus of enabling better functionality via a superior solutions, basically. ~harring
pgpaSEqVUvgzj.pgp
Description: PGP signature
