Re: [gentoo-portage-dev] [RFC] Depending on "active" version

[Kevin F. Quinn]

On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner <antarus@g.o> 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).

>  All resolution is a brute
> force metadata search; and assuming we had all the necessary data up
> front, we can optimize the search there (see pkgcore and restriction
> subsystem) versus IMHO doing a 'dumb' search and then running through
> a list of criteria for inclusion.
>
> This is the same reason why built_with_use in pkg_setup is really just
> use_deps; these metadata should be included during resolution, not
> after.

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.

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

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.

-- 
Kevin F. Quinn