Kevin F. Quinn wrote:
> On Wed, 31 Jan 2007 12:27:10 -0500
> Alec Warner <[EMAIL PROTECTED]> wrote:
>
>>> Hmm; one could get the same benefit by introducing a new interface
>>> (e.g. pkg_env_check()) which is defined to return true if the
>>> environment is ok, false otherwise (with some text to stdout,
>>> perhaps). The package manager would then run this function, after
>>> building the depgraph and finding the candidate packages to merge,
>>> for each candidate package - if any package fails is env_check,
>>> none of the packages get emerged. Note this is then completely
>>> independent of depgraph creation.
>>>
>>> In the 'tr1' example, I'd imagine something like this:
>>>
>>> use.local.desc: boost: Use boost library for tr1 rather than gcc's.
>>>
>>> ebuild:
>>>
>>> ...
>>> inherit ... toolchain-funcs versionator ...
>>> ...
>>> DEPEND=... boost? ( dev-libs/boost ) ...
>>> ...
>>> pkg_env_check() {
>>> use boost && return 0
>>> version_is_at_least "4.1" $(gcc-version) && return 0
>>> echo "Either USE boost, or switch to gcc later than 4.1"
>>> }
>>>
>>>
>>> (with a default definition, "pkg_env_check() { return 0; }" )
>> In an ideal system you'd want this stuff in the metadata cache so that
>> the resolver can deal with it up front.
>
> You're talking about the metadata on the host, rather than the stuff on
> the rsync servers? I'm not sure you could cache the results even on
> the host - you would need to know what could affect the results so as
> to know when the cached information is out of date and has to be
> recalculated. That would either have to checked on every emerge, or
> made a separate switch (i.e. rely on the user to tell emerge when the
> environment has changed).
I am talking about the host yeah; cache was a bad term on my part;
obviously you cannot cache stuff like this.
> My concern about dynamic dependencies runs to use deps, as well :)
> One could consider use-deps to be a special case of Marius' active
> checks. "how pkg P was built" isn't so different from "slot S of P is
> active" in terms of dep-graph creation; both are asking about the
> state of host & target systems, rather than the tree.
>
> In the case of USE deps, things are saner because the data doesn't
> change without the package manager knowing about it. Effectively the
> depgraph becomes static w.r.t. the tree + installation record (rather
> than just static w.r.t. the tree). With active checks implemented in
> the depgraph, however, that is no longer the case - the depgraph can
> change independently of the tree and the installation record.
>
I am unsure how fast these types of checks would or could be. I mean we
can add arbitrary key caching and arbitrary key matching, but then that
grows the cache substantially and probably slows down dependency
resolution. As you stated, some things just can't be cached properly
and still have value.
>> With that said, I'm not sure how easy it would be to rewrite that
>> code; and this is simpler in that it's just a few bash functions as
>> opposed to more resolver foo.
>
> There's a lot to be said for keeping things simple, of course :) It's
> easy enough to mess up things like dep-graphs in any case - introducing
> these sorts of dynamic dependencies can render it substantially more
> complex.
I think the complexity exists already though; currently we are just
hiding it, requiring people to find workarounds in an otherwise complex
playground of building packages.
>
> Another way to look at it, is to consider how often this sort of thing
> comes up. My understanding is that it is relatively rare; across the
> 10,000+ packages in the tree only a handful use 'built_with_use' fex.
> That makes a strong case for having a simple solution in the near term,
> and re-visit if it becomes commonplace.
>
I think your understanding is off then. A quick grep (qrep -H
built_with_use | wc -l) gives me 814 calls to 'built_with_use' (qgrep is
in portage-utils).
If you grep through eclasses you will also see 53 separate calls; so you
can imagine what the real usage could be (definately at least 1/20th the
tree, not something I'd call minor).
--
gentoo-portage-dev@gentoo.org mailing list
