1 |
On Thu, 1 Apr 2010 00:56:08 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> Actually, I'm well aware I did. See, if PMS wasn't developed in a |
4 |
> void you'd know build, bootstrap, acl and friends were already a |
5 |
> known issue with use cycle breaking. |
6 |
|
7 |
So since it's a known issue, why are you pushing for VALID_USE "because |
8 |
it allows cycle breaking" without also pushing for a solution to flags |
9 |
that can't be toggled at the same time? |
10 |
|
11 |
> pkg_setup: ran just before the build of the pkg, after the pkg's |
12 |
> DEPENDS are all built. Meaning you *can* do has_version checks, |
13 |
> kernel config checks, etc, because the proceeding deps are now |
14 |
> satisfied. |
15 |
|
16 |
Except that they might change, because, as we established on the bug, |
17 |
two packages that aren't interdependent can affect each other's |
18 |
assumptions, and can be built in parallel. pkg_pretend does not alter |
19 |
the problem here. |
20 |
|
21 |
> Cherry picking the argument again. Main != whole, meaning the |
22 |
> majority reason I could see w/in council logs for supporting |
23 |
> pkg_pretend was USE constraint validation. |
24 |
> |
25 |
> As I've said, and as you seem to finally understand, VALID_USE isn't |
26 |
> a replacement for pkg_pretend- it just replaces the *main* usage of |
27 |
> it. |
28 |
|
29 |
You said on the bug that you wanted pkg_pretend removed in favour of |
30 |
VALID_USE. I don't object to VALID_USE; I object to you claiming that |
31 |
it replaces pkg_pretend, and I object to you claiming that using |
32 |
VALID_USE instead of pkg_pretend is enough to allow cycle breaking. |
33 |
|
34 |
> > Simply adding VALID_USE won't let you do cycle breaking. You also |
35 |
> > need extensive lists of which flags for which packages can safely |
36 |
> > be toggled and when without breaking the system, and the only way |
37 |
> > you'll get those lists is if developers care enough to update their |
38 |
> > ebuilds to provide them. |
39 |
> |
40 |
> That's one view, but sure, I'll run with it. |
41 |
> |
42 |
> The thing is, *without* VALID_USE you cannot do use cycle breaking |
43 |
> *period*. executable vs data for the representation of the |
44 |
> constraints (as I've spelled out for you 3 times now). |
45 |
|
46 |
You also can't do it *with* VALID_USE, unless you also have extensive |
47 |
help from ebuilds. Why are you pushing for VALID_USE without also |
48 |
proposing a way for the package mangler to be told which flags it can |
49 |
change? |
50 |
|
51 |
> pkg_pretend however completely disallows even *doing* use cycle |
52 |
> breaking. How in the hell is that a better next step? |
53 |
|
54 |
pkg_pretend is a pragmatic, cheap solution that solves a larger number |
55 |
of problems, whilst not ruling out anything that Portage will |
56 |
realistically be able to do in a relevant timeframe. |
57 |
|
58 |
If, in the distant future, Portage supports use cycle breaking, then |
59 |
people can switch their ebuilds to use VALID_USE when they're also |
60 |
updating their ebuilds to export the cycle breaking information the |
61 |
package mangler requires to do it without trashing a system. But since |
62 |
we don't know exactly what that information looks like yet, we might as |
63 |
well just stick with the single solution that solves all of the |
64 |
problems. |
65 |
|
66 |
-- |
67 |
Ciaran McCreesh |