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 <a...@gentoo.org> 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
