All,

mgorny opened up a bug[1], which requests for all eclasses that use the
'prefix' USE-flag to be "fixed" to add 'prefix' to IUSE.

While the 'prefix' USE-flag has since its introduction belonged to that
group of USE-flags that are not supposed to be set by the user
him/herself, it is not covered by any definition claiming it is.
(Judging by PMS.) Other flags in this category are the userland_*,
elibc_*, kernel_*, x86, amd64, etc. flags.

With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
has been added to PMS, that finally makes a statement on what's supposed
to be in IUSE, and what not[2]. To me, this patch means that things like
userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an
ebuild/eclass (and hence should b removed). 'prefix', on the other
hand, should be added to IUSE of those ebuilds/eclasses that use them.

For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be
enriched with IMPLICIT_IUSE="prefix".

For all currently Council approved EAPIs this means 'prefix' has to be
added to IUSE. While said bug[1] is assigned to the prefix team, I feel
this is actually for the coordinating role, since prefix does not own
most of the ebuilds/eclasses that would need changes.

In case you wonder why this is a problem now, Portage/repoman has a rule
that USE-flags that are masked in the profiles implicitly are defined.
Since USE=prefix is masked in the base profile, for Portage this
USE-flag is always defined. With the updated PMS documentation,
however, it is supposed to act differently.

Since this would require quite some work, I'd like to hear what the
(dev) community thinks of this, if at all, before I'll Cc all
responsible teams and maintainers to fix the eclasses, followed by
ebuilds.


[1] https://bugs.gentoo.org/show_bug.cgi?id=433894
[2] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d0 53bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e1 2c2f906

--
Fabian Groffen
Gentoo on a different level

On Fri, 7 Sep 2012 19:32:12 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> mgorny opened up a bug[1], which requests for all eclasses that use
> the 'prefix' USE-flag to be "fixed" to add 'prefix' to IUSE.

Please do not suggest that I am the one requesting this to be "fixed".
I just have opened the bug because Ciaran failed to do that aside to
complaining on the new eclasses on mailing list.

> For all currently Council approved EAPIs this means 'prefix' has to be
> added to IUSE. While said bug[1] is assigned to the prefix team, I
> feel this is actually for the coordinating role, since prefix does
> not own most of the ebuilds/eclasses that would need changes.

To be more exact, I just wanted the Prefix team to decide on how we
should go with it, and how should new eclasses use the prefix flag.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=433894

--
Best regards,
Michał Górny

On 9/7/2012 10:32 AM, Fabian Groffen wrote:


With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
has been added to PMS, that finally makes a statement on what's supposed
to be in IUSE, and what not[2]. To me, this patch means that things like
userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an
ebuild/eclass (and hence should b removed). 'prefix', on the other
hand, should be added to IUSE of those ebuilds/eclasses that use them.


What, exactly, is the difference -- the principle behind the "should"s
above? USE_EXPAND? Probably more a problem of me being lazy than
anything being wrong with it, but [2] reads like Greek to me.



For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be
enriched with IMPLICIT_IUSE="prefix".

For all currently Council approved EAPIs this means 'prefix' has to be
added to IUSE.


I haven't looked into IMPLICIT_IUSE too carefully, but ... shouldn't
this be... implicit? Sorry, I'm being super lazy and not reading
anything here.



In case you wonder why this is a problem now, Portage/repoman has a rule
that USE-flags that are masked in the profiles implicitly are defined.


Probably making a total ass of myself at this point but... could you
define "defined"? I'm guessing I'd understand how to get flags masked
implicitly if I read the IMPLICIT_IUSE stuff? Or do you mean "are
defined implicitly" (in which case, again, I don't see why we'd need to
make them explicit).



[2] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d0 53bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e1 2c2f906


Apologies for these questions -- in my defense, being both lazy and
ignorant puts me at a real disadvantage here


-gmt

On 07-09-2012 16:38:15 -0700, Gregory M. Turner wrote:
> On 9/7/2012 10:32 AM, Fabian Groffen wrote:
> > With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
> > has been added to PMS, that finally makes a statement on what's supposed
> > to be in IUSE, and what not[2]. To me, this patch means that things like
> > userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an
> > ebuild/eclass (and hence should be removed). 'prefix', on the other
> > hand, should be added to IUSE of those ebuilds/eclasses that use them.
>
> What, exactly, is the difference -- the principle behind the "should"s
> above? USE_EXPAND? Probably more a problem of me being lazy than
> anything being wrong with it, but [2] reads like Greek to me.

USE_EXPAND - yes.

> > For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be
> > enriched with IMPLICIT_IUSE="prefix".
> >
> > For all currently Council approved EAPIs this means 'prefix' has to be
> > added to IUSE.
>
> I haven't looked into IMPLICIT_IUSE too carefully, but ... shouldn't
> this be... implicit? Sorry, I'm being super lazy and not reading
> anything here.

The idea here is that the package manager knows in advance which
USE-flags are valid for the ebuild. I called that 'defined' lateron in
this mail.
Normally, if you use a USE-flag, you add them to IUSE of the ebuild.
However, some USE-flags have been considered too general to put them in
there in the past.
Most of those are arch-related, keyword, userland_*, etc. IMPLICIT_IUSE
is meant to accomodate this case for ordinary USE-flags, like 'prefix'.
That is, a USE-flag added to IMPLICIT_IUSE is always there, and hence no
need to add it to IUSE of the ebuild. This only works for EAPI 5
(assuming it gets accepted), though.

> > In case you wonder why this is a problem now, Portage/repoman has a rule
> > that USE-flags that are masked in the profiles implicitly are defined.
>
> Probably making a total ass of myself at this point but... could you
> define "defined"? I'm guessing I'd understand how to get flags masked
> implicitly if I read the IMPLICIT_IUSE stuff? Or do you mean "are
> defined implicitly" (in which case, again, I don't see why we'd need to
> make them explicit).

There is probably different wording for this, but what I meant was that
ebuilds can only use USE-flags that are defined to be used by the
ebuild. The latter is done through listing it in IUSE in the ebuild.

> > [2] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d0 53bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e1 2c2f906
>
> Apologies for these questions -- in my defense, being both lazy and
> ignorant puts me at a real disadvantage here

The real question here is if the dev community agrees on adding 'prefix'
conditionally to IUSE in many eclasses and ebuilds.


--
Fabian Groffen
Gentoo on a different level

On Mon, 10 Sep 2012 10:18:56 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> Normally, if you use a USE-flag, you add them to IUSE of the ebuild.
> However, some USE-flags have been considered too general to put them
> in there in the past.

That's not exactly why. Historically (as in, way before EAPI days) IUSE
was purely a visual thing: it was used for emerge -pv output, but not
anything affecting behaviour. Thus, people didn't list things that
weren't worth showing to the user.

That all went out of the window when we got package.use, new-use
support, etc. At that point, IUSE had to be fairly accurate. It became
even more important when we introduced use dependencies and use
dependency defaults. Not having an accurate IUSE means that
dependencies like cat/pkg[prefix(-)] can't work. This is why the
original EAPI 3 tidied all this up properly.

Unfortunately, due to EAPI 3 becoming EAPI 4 and having some features
removed, use dependency defaults ended up being "supported" without
having the necessary information to make them work correctly in all
cases, and prefix ended up being supported but without the "prefix" use
flag being special.

So really we should just not support prefix at all in any EAPI before
5, and not have the whole "but define those prefix variables anyway"
hack in eclasses. But apparently people are preferring to go to great
lengths not to have to use newer EAPIs...

--
Ciaran McCreesh

On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote:
> So really we should just not support prefix at all in any EAPI before
> 5, and not have the whole "but define those prefix variables anyway"
> hack in eclasses. But apparently people are preferring to go to great
> lengths not to have to use newer EAPIs...

I think the problem is that this vision doesn't really give a migration
path, even when people are willing to move on to EAPI 5.

Personally, this vision doesn't really encourage me to push any changes
for this, since Portage seems to handle it well.


--
Fabian Groffen
Gentoo on a different level

On Mon, 10 Sep 2012 11:25:05 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote:
> > So really we should just not support prefix at all in any EAPI
> > before 5, and not have the whole "but define those prefix variables
> > anyway" hack in eclasses. But apparently people are preferring to
> > go to great lengths not to have to use newer EAPIs...
>
> I think the problem is that this vision doesn't really give a
> migration path, even when people are willing to move on to EAPI 5.

It gives you a marvellous opportunity to get the tree using newer EAPIs
as you prefixify things.

> Personally, this vision doesn't really encourage me to push any
> changes for this, since Portage seems to handle it well.

No, it really doesn't. Portage's error checking just isn't good enough
yet that you notice the breakage. "Appears to work for some subset
of inputs if you don't look too closely" is not "works".

--
Ciaran McCreesh

On 10-09-2012 10:28:26 +0100, Ciaran McCreesh wrote:
> On Mon, 10 Sep 2012 11:25:05 +0200
> Fabian Groffen <grobian@gentoo.org> wrote:
> > On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote:
> > > So really we should just not support prefix at all in any EAPI
> > > before 5, and not have the whole "but define those prefix variables
> > > anyway" hack in eclasses. But apparently people are preferring to
> > > go to great lengths not to have to use newer EAPIs...
> >
> > I think the problem is that this vision doesn't really give a
> > migration path, even when people are willing to move on to EAPI 5.
>
> It gives you a marvellous opportunity to get the tree using newer EAPIs
> as you prefixify things.

You ignore the current state of affairs, IMO.

> > Personally, this vision doesn't really encourage me to push any
> > changes for this, since Portage seems to handle it well.
>
> No, it really doesn't. Portage's error checking just isn't good enough
> yet that you notice the breakage. "Appears to work for some subset
> of inputs if you don't look too closely" is not "works".

This really deviates from getting us to a solution.


--
Fabian Groffen
Gentoo on a different level