Re: [gentoo-dev] Addressing GLEP-62 itself

[Brian Harring]

On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote:
> On Tue, 25 Sep 2012 14:47:33 -0400
> Ian Stakenvicius <axs@g.o> wrote:
>
> > Based on the above I do expect the reference implementation would also
> > need to change.  I expect, for instance, that the PM's
> > metadata-handling would need to occur as normal even though none of
> > the package's phase functions would run, that is, *DEPEND
> > (realistically RDEPEND as that should be the only one affected here,
> > maybe PDEPEND too) and USE/PKGUSE would get updated.  Since portage
> > would not be re-emerging the package from the tree the original ebuild
> > would remain.
>
> Yes, unless I'm missing something that's the intent. I will re-read
> and update the GLEP a bit sometime this week.

There's a fairly strong user interaction component here, along w/ 
potential nastyness for ebuilds (the proposal assume that a flag will 
be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I 
guarantee instances where that fails can be found in the tree if a 
basic audit was done).  Additionally, this *is* useless if it's done 
in a form the UI an't display/handle; Ciaran may bitch about 
REQUIRED_USE's UI (which I knew going in was going to be 
problematic, just to be clear), but he's right on that front.

Additionally, this needs to be thought out how it'll interact with 
eclasses; what stacking, etc.  It doesn't cover the basics there to 
say the least.

Pretty much, this needs an implementation, partial conversion of the 
tree to demonstrate it.

Just to prove that fricking point; if you had tried implementing this, 
a full investigation of what's involved alone, you'd have spotted that 
the core of the proposal is based on a wrong assumption.

Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB.  

Literally, USE=-x RDEPEND="x? ( dev-util/diffball )", the RDEPEND in 
the vdb is going to be "".

The retort is "meh, that's minor"; the fact this was missed doesn't 
inspire confidence; further, aside from the fact that writing 
finalized deps to the VDB ie, an accurate form of the deps- they're 
locked at that point, a smart PM can take advantage of that to avoid 
reading USE/IUSE till it's needed.  This has measurable speed impact; 
if in doubt, rebuild a tree without it- that little trick I came up 
with first in pkgcore and it works on two fronts; 1) parsing is 
quicker, less nodes/smaller tree, 2) a smart PM can lazy load the 
USE/IUSE for performance gain.  This is why portage/pkgcore were 
intentionally modified to do this; paludis may do it, haven't looked.

My views, if the council is sane they'll slap it back down stating 
"prove it's a viable solution"; regardless of my views of the proposal 
(that it's the wrong way to solve it), it's not ready for an actual 
vote since approving it without actually verifying it could work makes 
things fucktons worse.


> > I expect, as a corollary to this, that a rebuild would be necessary if
> > (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty
> > (--newuse) or resulted in any flags that are in USE
> > (--reinstall=changed-use).  IMO this would be necessary to ensure the
> > local ebuild copy and all related metadata for it gets updated in vdb.
>
> I think that's a common package manager logic and it's out of scope
> of the GLEP.

Portage doesn't do physical updates last I saw- if it did, well, 
that's fairly dangerous.  Only thing stored in the VDB is the ebuild 
and the environment dump, and the environment dump is what's ran from.

You cannot sanely pick part the dump and try to intermix current 
ebuilds; rephrasing, I'll kick in the head anyone who tries that.

We used to do that shit; it broke, frequently.  Env saving took a long 
time to get landed across the board- doing what you're proposing the 
PM should do breaks those guarantess and is a step back on that front 
alone.  Basically, not happening, if it is, a series of bugs need 
filing.

What portage does is that if it sees an ebuild in the tree that 
matches, it uses the deps from the tree; that's wholy different from 
what you think is happening in the vdb.

Additionally, portage is the only PM that does this; the rest of the 
PMs treat the vdb ebuild as a constant- without extreme care, or some 
form of insane deptree comparison, you can't just swap in what a new 
ebuild has and expect it to work in all cases.

~harring