On Tue, 30 Jan 2007 08:25:31 -0800
Brian Harring <[EMAIL PROTECTED]> wrote:

> On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote:
> > Sometimes a package has to depend on a specific version of a 
> > slotted package being the "active" one to build correctly, like in 
> > the current "tr1" discussion on -dev [1] or with packages that 
> > depend on the running kernel.
> 
> tr1 is partially addressed via addition of a 'binding' modifier for 
> rdeps, to state that ||() deps are locked down after compilation.

And how would that solve the actual issue of expressing "I need /usr/bin/gcc to 
run gcc-4.1 and not gcc-3.4"?
The lockdown of || deps is a completely separate issue, unless I'm missing 
something.

> > The idea is to add a special category (let's call it "active" for 
> > now) that has the following properties:
> > - this category doesn't exist in portdir or vdb (= no ebuilds)
> > - when portage ($pkgmanager) encounters a "active/foo" atom in a 
> > dependency string it executes some special code (e.g. 
> > "$PORTDIR/scripts/active-check/foo =active/foo-1") to determine if 
> > that atom is satisfied
> 
> Non deterministic resolution; previous steps in the graph can cause 
> that value to flip to a different setting by the time the 'dep' is 
> encountered.

Ok, that's a problem, though for the use cases at hand (gcc and kernel) it 
would be mostly irrelevant.

> That's ignoring the kick in the nads usage of this will due to 
> resolution...

Neglectable IMO, it's not such a common use case anyway, and I don't think I 
have to compare it to the current "solution" (die in setup or compile).

> > (and yes, this kinda goes with multi-repo/multi-format support)
> 
> Don't really see how this enables multiple standalone repos in any 
> sane way, so that one requires justification...

Where did I say anything about enabling? It would need more or less a separate 
repository (dbapi) instance, so it would require such support.

Marius
-- 
gentoo-portage-dev@gentoo.org mailing list

Reply via email to