| 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 |
Archives