1 |
Kevin F. Quinn wrote: |
2 |
> On Wed, 31 Jan 2007 12:27:10 -0500 |
3 |
> Alec Warner <antarus@g.o> wrote: |
4 |
> |
5 |
>>> Hmm; one could get the same benefit by introducing a new interface |
6 |
>>> (e.g. pkg_env_check()) which is defined to return true if the |
7 |
>>> environment is ok, false otherwise (with some text to stdout, |
8 |
>>> perhaps). The package manager would then run this function, after |
9 |
>>> building the depgraph and finding the candidate packages to merge, |
10 |
>>> for each candidate package - if any package fails is env_check, |
11 |
>>> none of the packages get emerged. Note this is then completely |
12 |
>>> independent of depgraph creation. |
13 |
>>> |
14 |
>>> In the 'tr1' example, I'd imagine something like this: |
15 |
>>> |
16 |
>>> use.local.desc: boost: Use boost library for tr1 rather than gcc's. |
17 |
>>> |
18 |
>>> ebuild: |
19 |
>>> |
20 |
>>> ... |
21 |
>>> inherit ... toolchain-funcs versionator ... |
22 |
>>> ... |
23 |
>>> DEPEND=... boost? ( dev-libs/boost ) ... |
24 |
>>> ... |
25 |
>>> pkg_env_check() { |
26 |
>>> use boost && return 0 |
27 |
>>> version_is_at_least "4.1" $(gcc-version) && return 0 |
28 |
>>> echo "Either USE boost, or switch to gcc later than 4.1" |
29 |
>>> } |
30 |
>>> |
31 |
>>> |
32 |
>>> (with a default definition, "pkg_env_check() { return 0; }" ) |
33 |
>> In an ideal system you'd want this stuff in the metadata cache so that |
34 |
>> the resolver can deal with it up front. |
35 |
> |
36 |
> You're talking about the metadata on the host, rather than the stuff on |
37 |
> the rsync servers? I'm not sure you could cache the results even on |
38 |
> the host - you would need to know what could affect the results so as |
39 |
> to know when the cached information is out of date and has to be |
40 |
> recalculated. That would either have to checked on every emerge, or |
41 |
> made a separate switch (i.e. rely on the user to tell emerge when the |
42 |
> environment has changed). |
43 |
|
44 |
I am talking about the host yeah; cache was a bad term on my part; |
45 |
obviously you cannot cache stuff like this. |
46 |
|
47 |
> My concern about dynamic dependencies runs to use deps, as well :) |
48 |
> One could consider use-deps to be a special case of Marius' active |
49 |
> checks. "how pkg P was built" isn't so different from "slot S of P is |
50 |
> active" in terms of dep-graph creation; both are asking about the |
51 |
> state of host & target systems, rather than the tree. |
52 |
> |
53 |
> In the case of USE deps, things are saner because the data doesn't |
54 |
> change without the package manager knowing about it. Effectively the |
55 |
> depgraph becomes static w.r.t. the tree + installation record (rather |
56 |
> than just static w.r.t. the tree). With active checks implemented in |
57 |
> the depgraph, however, that is no longer the case - the depgraph can |
58 |
> change independently of the tree and the installation record. |
59 |
> |
60 |
|
61 |
I am unsure how fast these types of checks would or could be. I mean we |
62 |
can add arbitrary key caching and arbitrary key matching, but then that |
63 |
grows the cache substantially and probably slows down dependency |
64 |
resolution. As you stated, some things just can't be cached properly |
65 |
and still have value. |
66 |
|
67 |
>> With that said, I'm not sure how easy it would be to rewrite that |
68 |
>> code; and this is simpler in that it's just a few bash functions as |
69 |
>> opposed to more resolver foo. |
70 |
> |
71 |
> There's a lot to be said for keeping things simple, of course :) It's |
72 |
> easy enough to mess up things like dep-graphs in any case - introducing |
73 |
> these sorts of dynamic dependencies can render it substantially more |
74 |
> complex. |
75 |
|
76 |
I think the complexity exists already though; currently we are just |
77 |
hiding it, requiring people to find workarounds in an otherwise complex |
78 |
playground of building packages. |
79 |
|
80 |
> |
81 |
> Another way to look at it, is to consider how often this sort of thing |
82 |
> comes up. My understanding is that it is relatively rare; across the |
83 |
> 10,000+ packages in the tree only a handful use 'built_with_use' fex. |
84 |
> That makes a strong case for having a simple solution in the near term, |
85 |
> and re-visit if it becomes commonplace. |
86 |
> |
87 |
|
88 |
I think your understanding is off then. A quick grep (qrep -H |
89 |
built_with_use | wc -l) gives me 814 calls to 'built_with_use' (qgrep is |
90 |
in portage-utils). |
91 |
|
92 |
If you grep through eclasses you will also see 53 separate calls; so you |
93 |
can imagine what the real usage could be (definately at least 1/20th the |
94 |
tree, not something I'd call minor). |
95 |
-- |
96 |
gentoo-portage-dev@g.o mailing list |