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

[Michał Górny]

On Wed, 26 Sep 2012 03:29:17 -0700
Brian Harring <ferringb@×××××.com> wrote:

> On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote:
> > 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.
>
> ^^^ This point still needs addressing.

What kind of addressing? The user interaction works like usual --
portage lists a bunch of flags, some of them may have additional
hammers or sickles to mean that they will not trigger the rebuild.
Nothing more is required.

What is even more important, there is nothing new to learn
for the user. In fact, he doesn't need anything new from UI. He will
just set the flag like he did 10 years ago.

> > > 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?
>
> Eclass stacking here matters; if it's stacked, it means ebuilds have
> to use out of bound (ie, other vars) to tell the eclass when it
> shouldn't mark a flag as runtime toggable.  If it's not stacked by
> the pm, then they have to manually stack; that differs from the norm
> and makes it easier to screwup; however; does allow for them to
> filter, albeit a slight pain in the ass doing so.
>
> There's a choice there, and the answer matters, so yes, you should
> actually have a complete glep before trying to shove it up to the
> council and extract a vote out of them.  Lest the intention is to just
> have them kick it back to the curb...

As others have said, we're not stacking it. Using it in eclasses
is whacky and should be avoided. End of the story.

> > > 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.
>
> Frankly I don't fully buy that you were aware of this issue from the
> start of the proposal; the wording partially covers it however.
> Ddoesn't call it out, but via tha req it dumps it on the package
> manager developers heads to sort it- which already is the case.
> Binpkgs minimally weren't addressed which is why I still don't think
> this was actually spotted up front.

We talked about it, don't you remember? That's why I have updated
the spec and put the whole implementation details thing with special
note what needs to be stored in metadata.

-- 
Best regards,
Michał Górny