Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Addressing GLEP-62 itself (http://www.linux-archive.org/gentoo-development/707312-addressing-glep-62-itself.html)

Ian Stakenvicius 09-25-2012 06:47 PM

Addressing GLEP-62 itself
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/09/12 02:03 PM, Ian Stakenvicius wrote:
> Since hasufell brought it up, and as I believe he's going to ask
> Council to approve it before moving forward with this proposal
> towards including it in an EAPI, I wanted to clarify some of the
> points mentioned:
>
> --- Quote, GLEP-62 ---
>> Specifications, paragraph 3: The package manager should treat
>> flags listed in IUSE_RUNTIME as regular USE flags, except for the
>> following:
>
>> 1. enabling or disabling any of the flags must not involve
>> rebuilding the package,
>
>> 2. it should be possible for a package manager to change those
>> flags on a installed package without using the original ebuild,
>
>> 3. when queried on a installed package, the package manager must
>> consider a particular flag enabled only if its dependencies are
>> satisfied already,
>
>> 4. the flags may be listed in the visual output in a distinct way
>> to inform the user that they affect runtime dependencies only.
>
>
> #2 -- this would, if I'm understanding it properly, mean that the
> IUSE list and the IUSE_RUNTIME list in the 'original ebuild' (ie in
> vdb) would be ignored on an emerged package in favour of the
> ebuild(s) in the tree, right? I'm not so sure this is a good
> idea.
>
> IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild
> and one of those use flags that changed have been triggered or
> de-triggered I expect that the package should be rebuilt, to keep
> it consistent with current practices.
>
> IE2, shouldn't the original ebuild be what's used to trigger the
> skip-rebuild functionality, rather than the in-tree ebuild?
>
>
> #3 -- this seems to imply to me, that the state of a package's
> effective USE could be modified solely on the basis of a
> dependency existing or not and have nothing to do with what the
> flag was set to at emerge time. IE, *not* the state of USE in the
> vdb. I think this would also be a problem.
>
> In order to properly handle dependency resolution (which IMO we
> should do, because these are still USE flags) I think all use flag
> settings should still be honoured by the PM and related metadata in
> the vdb be updated for IUSE_RUNTIME flags identically to how it
> would be done if IUSE_RUNTIME wasn't set.
>
>
> Thoughts?
>


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.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBh/EUACgkQ2ugaI38ACPAFfAD/UsYVQg6ZkwlsaWIafuFr0sqC
7IuvqIgroxNWJ/5XRS8BAJ+5awXZanZftOmFWRmDUAxOvPc8+J073dAn78N0CPdB
=zKzg
-----END PGP SIGNATURE-----

Michał Górny 09-25-2012 06:55 PM

Addressing GLEP-62 itself
 
On Tue, 25 Sep 2012 14:03:36 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Since hasufell brought it up, and as I believe he's going to ask Council
> to approve it before moving forward with this proposal towards including
> it in an EAPI, I wanted to clarify some of the points mentioned:
>
> - --- Quote, GLEP-62 ---
> > Specifications, paragraph 3: The package manager should treat flags
> > listed in IUSE_RUNTIME as regular USE flags, except for the
> > following:
> >
> > 1. enabling or disabling any of the flags must not involve
> > rebuilding the package,
> >
> > 2. it should be possible for a package manager to change those
> > flags on a installed package without using the original ebuild,
> >
> > 3. when queried on a installed package, the package manager must
> > consider a particular flag enabled only if its dependencies are
> > satisfied already,
> >
> > 4. the flags may be listed in the visual output in a distinct way
> > to inform the user that they affect runtime dependencies only.
>
>
> #2 -- this would, if I'm understanding it properly, mean that the IUSE
> list and the IUSE_RUNTIME list in the 'original ebuild' (ie in vdb)
> would be ignored on an emerged package in favour of the ebuild(s) in
> the tree, right? I'm not so sure this is a good idea.

The exact opposite. The PM should use vdb whenever no non-IUSE_RUNTIME
flags have changed in vdb and no other reasons have caused it to use
the ebuild repository.

> IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild and
> one of those use flags that changed have been triggered or
> de-triggered I expect that the package should be rebuilt, to keep it
> consistent with current practices.

If --newuse triggers that, the ebuild will be used.

> IE2, shouldn't the original ebuild be what's used to trigger the
> skip-rebuild functionality, rather than the in-tree ebuild?

I already said that :).

> #3 -- this seems to imply to me, that the state of a package's
> effective USE could be modified solely on the basis of a dependency
> existing or not and have nothing to do with what the flag was set to
> at emerge time. IE, *not* the state of USE in the vdb. I think this
> would also be a problem.

No, you're overestimating it. It just means that the package manager
should first install the dependencies, and then update USE in vdb,
and not the other way around.

--
Best regards,
Michał Górny

Michał Górny 09-25-2012 06:58 PM

Addressing GLEP-62 itself
 
On Tue, 25 Sep 2012 14:47:33 -0400
Ian Stakenvicius <axs@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.

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

--
Best regards,
Michał Górny

Brian Harring 09-25-2012 07:54 PM

Addressing GLEP-62 itself
 
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@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

Michał Górny 09-26-2012 06:02 AM

Addressing GLEP-62 itself
 
On Tue, 25 Sep 2012 12:54:39 -0700
Brian Harring <ferringb@gmail.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@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.

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

Brian Harring 09-26-2012 10:29 AM

Addressing GLEP-62 itself
 
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@gmail.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@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.

^^^ This point still needs addressing.


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


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

Were it, the performance impact should've been mentioned, and
quantified; con's are part of a normal glep.

Meaning.. wait for it... writing a prototype is required to get those
stats. ;)


> > > > Based on the above I do expect the reference implementation
> > > > would alsoneed 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.
> > > >
> > > > 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*.

Added the full quote above. Read prior to the corollary; that's
proposing transferance of *depend from live tree to vdb; that's not
common- portage alone does that, and it's got faults that make it
unlikely you'll convince others to replicate that behaviour.

~harring

Alexis Ballier 09-26-2012 05:38 PM

Addressing GLEP-62 itself
 
On Wed, 26 Sep 2012 03:29:17 -0700
Brian Harring <ferringb@gmail.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@gmail.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@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.
>
> ^^^ This point still needs addressing.

IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
Also, the proposal doesn't assume flags are toggable at will, it assumes
they are useflags and obey the same rules.

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

It can't be stacked and it's not wise to do so; it is a simple bash
variable like tons of others in eclasses:
"""
Package managers not implementing this GLEP will consider
the ``IUSE_RUNTIME`` variable as an irrelevant bash variable
"""
"""
2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE
flags related to optional runtime dependencies (without prefixes
related to IUSE defaults).
"""

Treating bash variables as bash variables is rather the norm,
stacking is the exception. As I understand it, your only objection here
is that you want to see written 'IUSE_RUNTIME gets no special treatment'
in the proposal ?

A.

Brian Harring 09-26-2012 09:02 PM

Addressing GLEP-62 itself
 
On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote:
> On Wed, 26 Sep 2012 03:29:17 -0700
> Brian Harring <ferringb@gmail.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@gmail.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@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.
> >
> > ^^^ This point still needs addressing.
>
> IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
> Also, the proposal doesn't assume flags are toggable at will, it assumes
> they are useflags and obey the same rules.

I truly hate claims like this; "it's optional, so who cares if it's
whacky". Think through the proposal; for it to work reliably, it's
not optional. Same issue I've been y'all over the head with,
rendered/finalized vs raw/unfinalized deps being stored in the VDB.

All managers have to write unfinalized if that proposal goes through,
even if they don't support the optional toggling after the fact.

As for the UI... arguing "but it's optional!" doesn't give a blank
check for the UI angle. What the plan, more colorization and a new
char for emerge -vp? Because we're kind of running out of chars
there...

It's a simple enough request; one that wouldn't even need to be made
if there was code backing this proposal; on a related note, hell yes
I'm wary of having this dumped on manager authors heads and having to
be told "sort out the mess/make it so". So I'm asking y'all to at
least put in an equivalent time investment doing a quick prototype.

This isn't an unreasonable request, and has been the norm for most
gleps for a long while.


> > > > 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...
>
> It can't be stacked and it's not wise to do so; it is a simple bash
> variable like tons of others in eclasses:

It cannot be stacked because y'all are trying to shove this in as an
optional; unlike it's brother IUSE, which stacks.

As for "ons of others that don't stack"; very few actually influence
the package manager; ~14 roughly, minimally 5 of those stack (those
that don't, basically aren't lists).


> """
> Package managers not implementing this GLEP will consider
> the ``IUSE_RUNTIME`` variable as an irrelevant bash variable
> """
> """
> 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE
> flags related to optional runtime dependencies (without prefixes
> related to IUSE defaults).
> """
>
> Treating bash variables as bash variables is rather the norm,
> stacking is the exception. As I understand it, your only objection here
> is that you want to see written 'IUSE_RUNTIME gets no special treatment'
> in the proposal ?

My objection is punting it to the council till it's actually nailed
down/sane; having them mark it accepted means we're stuck w/ the
results if it turns out to be shit at the implementation/UI level as a
lot of us think it will be.

So yes, I want it actually finalized. Bluntly; there's zero point
having the council comment if it ain't finalized.

~harring

hasufell 09-26-2012 09:35 PM

Addressing GLEP-62 itself
 
On 09/26/2012 11:02 PM, Brian Harring wrote:
>
> So yes, I want it actually finalized. Bluntly; there's zero point
> having the council comment if it ain't finalized.
>

I understand. We probably have to wait for it then.

Meanwhile... is there an alternative approach?

Alexis Ballier 09-26-2012 10:25 PM

Addressing GLEP-62 itself
 
On Wed, 26 Sep 2012 14:02:57 -0700
Brian Harring <ferringb@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote:
> > On Wed, 26 Sep 2012 03:29:17 -0700
> > Brian Harring <ferringb@gmail.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@gmail.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@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.
> > >
> > > ^^^ This point still needs addressing.
> >
> > IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
> > Also, the proposal doesn't assume flags are toggable at will, it
> > assumes they are useflags and obey the same rules.
>
> I truly hate claims like this; "it's optional, so who cares if it's
> whacky". Think through the proposal; for it to work reliably, it's
> not optional. Same issue I've been y'all over the head with,
> rendered/finalized vs raw/unfinalized deps being stored in the VDB.
>
> All managers have to write unfinalized if that proposal goes through,
> even if they don't support the optional toggling after the fact.

Why? _Current_ PMs will rebuild the package. The point of this is just
to give them a hint that they do not need to rebuild it. We already
have an implementation actually: one that ignores the hint :)

> As for the UI... arguing "but it's optional!" doesn't give a blank
> check for the UI angle. What the plan, more colorization and a new
> char for emerge -vp? Because we're kind of running out of chars
> there...

How is this relevant ?

> It's a simple enough request; one that wouldn't even need to be made
> if there was code backing this proposal; on a related note, hell yes
> I'm wary of having this dumped on manager authors heads and having to
> be told "sort out the mess/make it so". So I'm asking y'all to at
> least put in an equivalent time investment doing a quick prototype.
>
> This isn't an unreasonable request, and has been the norm for most
> gleps for a long while.

I guess people do not want to invest time in writing code for something
doomed. The original request was just to have it 'accepted' so that an
implementation can start. If the implementation is good then make it
final, otherwise amend or reject the glep. This isn't unreasonable
either.

> > > > > 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...
> >
> > It can't be stacked and it's not wise to do so; it is a simple bash
> > variable like tons of others in eclasses:
>
> It cannot be stacked because y'all are trying to shove this in as an
> optional; unlike it's brother IUSE, which stacks.
>
> As for "ons of others that don't stack"; very few actually influence
> the package manager; ~14 roughly, minimally 5 of those stack (those
> that don't, basically aren't lists).

So it's not stacked, nothing else to discuss here :)

> > """
> > Package managers not implementing this GLEP will consider
> > the ``IUSE_RUNTIME`` variable as an irrelevant bash variable
> > """
> > """
> > 2. introduce additional ``IUSE_RUNTIME`` variable listing names of
> > USE flags related to optional runtime dependencies (without prefixes
> > related to IUSE defaults).
> > """
> >
> > Treating bash variables as bash variables is rather the norm,
> > stacking is the exception. As I understand it, your only objection
> > here is that you want to see written 'IUSE_RUNTIME gets no special
> > treatment' in the proposal ?
>
> My objection is punting it to the council till it's actually nailed
> down/sane; having them mark it accepted means we're stuck w/ the
> results if it turns out to be shit at the implementation/UI level as
> a lot of us think it will be.
>
> So yes, I want it actually finalized. Bluntly; there's zero point
> having the council comment if it ain't finalized.

Then the proposal itself should be discussed, not the implementation
details: chars for emerge -pv are irrelevant; you pointed the raw dep
issue in the VDB, that's good, but never said anything as of why they
can't additionally be stored, making this a non-issue for the
_proposal_ acceptation.

Anyway, without implementation I expect the council to just give a vote
of opinion, showing support or non-support to the proposal; the
proposal will be final only once the council will be happy with
portage's implementation. And I agree, the council doesn't need to be
involved to start the implementation, but knowing this proposal has
supporters will motivate people to do the implementation, vs. not even
being sure the idea itself will get some support.

Would you support the proposal if you are happy with its
implementation ?

A.


All times are GMT. The time now is 07:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.