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

[Michał Górny]

On Tue, 25 Sep 2012 12:54:39 -0700
Brian Harring <ferringb@×××××.com> wrote:

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

The proposal didn't cover eclasses at all. Is there a need to do so or
are we chasing some kind of perfection based on filling all unused
slots?

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

There's a footnote there, saying:

  The package manager has to ensure that all relevant information is
  stored in the installed package metadata.

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

What are you talking about? As far as I can see, we are talking here
about *full rebuild*.

-- 
Best regards,
Michał Górny