1 |
On Thu, 1 Apr 2010 00:31:09 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > Cycle breaking requires explicit instructions from the ebuilds in |
4 |
> > question (many of which are system things, which further |
5 |
> > complicates it) along with support from Portage, so it's a distant |
6 |
> > future, lot of work thing. |
7 |
> |
8 |
> Nonsense. Note I said 'use cycle', not the generic 'cycle |
9 |
> breaking'. USE induced cycles don't require explicit instructions |
10 |
> from the ebuild at all- the PM itself can search the solution space |
11 |
> (toggling flags as needed) to search out a way around the cycle. |
12 |
> |
13 |
> Consider user configuration w/ USE=X, pkg_a w/ DEPEND "X? ( pkg_b )", |
14 |
> pkg_b w/ DEPEND "pkg_a". To be clear, you're claiming that the |
15 |
> ebuild itself (and only the ebuild) is the the one able to state- |
16 |
> |
17 |
> emerge pkg_a[-X] |
18 |
> emerge pkg_a[X] |
19 |
> |
20 |
> As demonstrated, that cycle is easily broken. A lot of the cycles |
21 |
> users run into originate that way also. |
22 |
|
23 |
Congratulations. You just turned on 'build' and 'bootstrap', and turned |
24 |
off 'acl'. |
25 |
|
26 |
> And as I've already laid out in the bug, pkg_pretend has it's own set |
27 |
> of issues when compared to pkg_setup due to it being non temporal, |
28 |
> thus having high false positive potentials. |
29 |
|
30 |
These are exactly the same issues that pkg_setup has. You can't block a |
31 |
useful feature simply because developers could theoretically screw |
32 |
things up by using it. |
33 |
|
34 |
> The main council push for pkg_pretend was to move use constraint |
35 |
> checking to pre build. VALID_USE does that cleaner and enabling use |
36 |
> cycle breaking to be built; as such I'm pushing it up to them unless |
37 |
> someone can find significant *real* flaws. |
38 |
|
39 |
No, VALID_USE addresses a *subset* of the issues. It's not a |
40 |
replacement for pkg_pretend. |
41 |
|
42 |
> > When in the distant future Portage |
43 |
> > becomes able to deal with cycle breaking, ebuilds can be converted |
44 |
> > to use something like VALID_USE when they're also updated to export |
45 |
> > information on which of their flags can safely be toggled. |
46 |
> |
47 |
> You're being short sighted. VALID_USE is useful now for representing |
48 |
> use states that are allowed; that data itself is useful for use cycle |
49 |
> breaking. Added bonus of enabling better functionality via a |
50 |
> superior solutions, basically. |
51 |
|
52 |
Simply adding VALID_USE won't let you do cycle breaking. You also need |
53 |
extensive lists of which flags for which packages can safely be toggled |
54 |
and when without breaking the system, and the only way you'll get those |
55 |
lists is if developers care enough to update their ebuilds to provide |
56 |
them. |
57 |
|
58 |
-- |
59 |
Ciaran McCreesh |