Re: [gentoo-portage-dev] 2.1 release candidate soon?

[Jason Stubbs]

On Saturday 08 April 2006 21:48, Ned Ludd wrote:
> On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
> > On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> > > On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > > > FEATURES="buildpkg" ROOT=/ emerge gcc
> > > > rm -rf /dev/shm/foo
> > > >
> > > > ROOT=/dev/shm/foo emerge gcc -pvK
> > > >
> > > > Notice how it selects the incorrect deps?
> > > > IE: eselect cuz it's the first listed dep in the || ( ) vs the
> > > > gcc-config
> > >
> > > + When you already have a copy of gcc-config installed on / and in
> > > .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
> >
> > This should work. I believed I had fixed it by adding the use_binaries
> > parameter and code paths to dep_zapdeps. If it's not working then there must
> > be a bug left somewhere.
>
> Must be a bug left somewhere then. I just tested with
> Portage 2.1_pre7-r4 and the result is the same.

Got it. The bug was in bindbapi. For consistency's sake, I changed most of the
db["/"] to db[myroot] except where db["/"] is specifically required. However,
db[myroot]["bintree"].dbapi.* were all working with an empty repository as
bintree holds all the data and uses lazy initialization which bindbapi wasn't
triggering.

I've fixed the current use case and covered aux_get as well, but this bug could
easily come back if another method of bindbapi is used.

> > Having a quick look at the dep_zapdeps function, I can't see what but I think
> > I've discovered another bug. If use_binaries is true, porttree isn't checked
> > for matches which means that it'll fall through to the "last resort" code
> > when there's no matching binaries which could end up selecting an atom that
> > only has masked porttree matches.
>
> yikes.

This is and isn't the case. use_binaries is only enabled with -K so masking
doesn't take affect anyway.

--
Jason Stubbs
-- 
gentoo-portage-dev@g.o mailing list