[gentoo-dev] RFC: Reviving GLEP33

[gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

Hi folks,

I've been told that my use of eblits in dev-lang/php is something I
should get rid of as soon as possible. Suggested alternative by ferring:
use elibs.

So here goes: I want to see GLEP33[1] implemented in portage, so I can
shift the eblits core and currently global functions into elibs and
probably push the eblits I use for php into the same structure.

Basic question: what needs to be done to get this GLEP accepted and
implemented (it's current status is moribound)?

I extracted a list of things we (or rather the portage and all other PM
teams) need to do:

(1) create elibs() function to enable importing elibs
(2) extend repoman to handle new style elibs and eclass signing/checking
(3) profit ;)

Also, there're some question I have:
(1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of
"Cases where the constant [metadata] requirement is violated are known"
- who exactly are the current offenders?

(2) What's the dev community feeling on "The end of backwards
compatibility..." section in the GLEP? Personal opinion: when the
council reached consensus that old eclasses can be removed with due
last-rites, this section became obsolete. Just putting new-style
eclasses in their own dirs in eclass/ might again be an option. Please
discuss.

(3) Continuing with (2) do you feel we still need to provide a eclass
compat build (tarball) to users *still* not using a sane portage
version? If no, section "The start of a different phase of backwards
compatibility" can probably be stripped from the GLEP.

I silently assumed that our infra servers are running >=portage-2.1.4.4
here.

Instead of all the backwards-compatibility issues the GLEP deals with,
we could just sneak the implementation into EAPI4 and be done with it.

[1] http://www.gentoo.org/proj/en/glep/glep-0033.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4877 bytes --]

On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
> Hi folks,
> 
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by ferring:
> use elibs.
> 
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.
> 
> Basic question: what needs to be done to get this GLEP accepted and
> implemented (it's current status is moribound)?
> 
> I extracted a list of things we (or rather the portage and all other PM
> teams) need to do:
> 
> (1) create elibs() function to enable importing elibs

There's a caveat here; imagine one of the current PM's processing an 
EAPI=4 (or whatever) ebuild that uses elib- specifically there will be 
a global scope function invocation of a function that doesn't exist.

In the past, a minority of folk have raised complaints about this- it 
was never stated as best I know, but my assumption looking back is 
that it was due primarily to paludis getting pissy about ebuilds 
outputing anything during metadata sourcing (paludis at this point 
isn't pissy about it- mainly sinc eclasses can invoke die after all).

Managers should implementat that functionality; orthogonal to it, 
we've got a few options for how to deal with an EAPI=4 ebuild being 
metadata sourced by a <=EAPI3 PM (meaning, there will be a "command 
not found" spat to stderr during sourcing):

1) if 'elib' isn't defined, define it as a no-op w/in a 
profile.bashrc.  This doesn't work for paludis (they don't do profile 
bashrc at all), but works for pkgcore/portage- would silence the 
output in the majority basically.  This address gentoo-x86, but 
cleanly for stand alone repositories.

2) variation of #1, require consuming ebuilds to inherit an eclass 
that has the fallback no-op in it, rather than profile.  This would 
work for paludis, although again, it's gentoo-x86 specific and would 
be limited to overlays.  All standalone tree's would have to bundle 
their own eclass w/ the no-op.

3) glep55; note that I'm purely listing out options here, will leave 
the people pushing that glep to advocate it.

4) I should've thought of this a few years back, but frankly another 
option is to fix the @!#*ing package managers.  They should collect 
stdout/stderr output during sourcing, but only output it if the 
metadata sourcing resulted in an EAPI the PM supported.  If it's an 
EAPI the PM doesn't support, it wouldn't know how to write the cache 
for the ebuild anyways.

5) ignore that their may be output, and get on with our lives and 
implementing features.

From where I'm sitting, #4 should be implemented regardless of what 
solution is choosen.  Personally, I prefer #1, but #2 is easy enough 
to jam in if people really are bother by a couple of overlays making 
noise for people running a stale package manager.


Either way, this particular naggle needs a decision.


> (2) extend repoman to handle new style elibs and eclass signing/checking
> (3) profit ;)

I'd suggest breaking this up- specifically try to get elibs in, but do 
not bind their timelines/existance to eclass refactoring.


> Also, there're some question I have:
> (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of
> "Cases where the constant [metadata] requirement is violated are known"
> - who exactly are the current offenders?

Talk to vapier- he had some abuses of SLOT rewriting during merging 
(nasty hack that only works for portage) last time I knew.  Php had 
something similar at the time this glep was written, although that's 
since been removed.


> (2) What's the dev community feeling on "The end of backwards
> compatibility..." section in the GLEP? Personal opinion: when the
> council reached consensus that old eclasses can be removed with due
> last-rites, this section became obsolete. Just putting new-style
> eclasses in their own dirs in eclass/ might again be an option. Please
> discuss.

The env saving part of that section is no longer relevant, and the 
question of how long to keep eclasses around was addressed in the last 
council meeting:
http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt

Now, if eclasses2 went forward, how long to keep the old eclass 
directory around is a seperate question.


> Instead of all the backwards-compatibility issues the GLEP deals with,
> we could just sneak the implementation into EAPI4 and be done with it.

Exempting tweaking the inherit mechanism to use a new eclass location, 
a lot of the env saving bits of that glep are no longer relevant.

My suggestion?  Split this into two, elibs, and eclass refactoring.  
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[David Leverton]

On 2 August 2010 12:11, Brian Harring <ferringb@gmail.com> wrote:
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>> Hi folks,
>>
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible. Suggested alternative by ferring:
>> use elibs.

There's a couple of hundred lines of repeated metadata between
php-5.3.2 and php-5.3.3 - not identical, but similar enough that there
would be gains from factoring it out, and elibs won't help with that.
Am I understanding correctly in that you didn't use an eclass to avoid
cluttering up the main eclass directory with something specific to
this one package?  If so, it sounds like what you really want is
per-package eclasses (maybe with elibs as well to hold the
non-metadata code), which aren't covered by GLEP33 but ought to be
easy enough to add.

> There's a caveat here; imagine one of the current PM's processing an
> EAPI=4 (or whatever) ebuild that uses elib- specifically there will be
> a global scope function invocation of a function that doesn't exist.
>
> In the past, a minority of folk have raised complaints about this- it
> was never stated as best I know, but my assumption looking back is
> that it was due primarily to paludis getting pissy about ebuilds
> outputing anything during metadata sourcing

I can't speak for other people who may have complained, but it seems
to me that for ebuilds to be calling non-existent commands is fairly
obviously wrong, even if the consequences happen to be benign - not
the end of the world, but something that ought to be avoided if
possible.  (As far as paludis goes, it's more stdout that it used to
get upset about than stderr.)

> Managers should implementat that functionality; orthogonal to it,
> we've got a few options for how to deal with an EAPI=4 ebuild being
> metadata sourced by a <=EAPI3 PM (meaning, there will be a "command
> not found" spat to stderr during sourcing):
>
> [...]

Regarding the stuff about other standalone repositories, I don't think
it's a big deal to require them to carry a small amount of extra stuff
(only if they actually start using elibs in any case), considering all
the profiles, eclasses etc that they'd need anyway.  Overlays based on
the main Gentoo tree would be fine without any effort.

(For the record, +1 for GLEP55 from me, but the reasons for and
against don't need to be repeated yet again.)

> My suggestion?  Split this into two, elibs, and eclass refactoring.

Per-package eclasses would be beneficial IMHO regardless of the other
eclass stuff from 33, might be worth thinking about those as another
item (consistent with the existing design plans of course) if the rest
isn't going to happen soon.

Re: [gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On 08/02/2010 08:16 PM, David Leverton wrote:
> On 2 August 2010 12:11, Brian Harring <ferringb@gmail.com> wrote:
>> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>>> Hi folks,
>>> 
>>> I've been told that my use of eblits in dev-lang/php is something
>>> I should get rid of as soon as possible. Suggested alternative by
>>> ferring: use elibs.
> 
> There's a couple of hundred lines of repeated metadata between 
> php-5.3.2 and php-5.3.3 - not identical, but similar enough that
> there would be gains from factoring it out, and elibs won't help with
> that.

Sure. I was thinking of providing php.eclass with the common metadata
for php-5*, including patchset code, core DEPEND and the like. With the
php team rather stretched nowadays, it will take a few days before
that'll happen. I'm still trying to cope with the complexity of the
whole php eco-system.

> Am I understanding correctly in that you didn't use an eclass to
> avoid cluttering up the main eclass directory with something specific
> to this one package?

Yes. Actually, that was hoffie's goal, when he decided to use eblits.
I continued this and actually made php5_2-sapi.eclass obsolete by using
eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit
for this - the amount of code shared went through the ceiling.

> If so, it sounds like what you really want is per-package eclasses
> (maybe with elibs as well to hold the non-metadata code), which
> aren't covered by GLEP33 but ought to be easy enough to add.

It's actually covered by GLEP33:
http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring

And yes, it's one of it's most obvious advantages. I hate the clutter of
php-* eclasses with passion (I'm aware most of them serve a good purpose).

>> My suggestion?  Split this into two, elibs, and eclass
>> refactoring.
> 
> Per-package eclasses would be beneficial IMHO regardless of the
> other eclass stuff from 33, might be worth thinking about those as
> another item (consistent with the existing design plans of course) if
> the rest isn't going to happen soon.

If we can get that going asap without waiting, I'm all for it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[David Leverton]

On 2 August 2010 22:40, Matti Bickel <mabi@gentoo.org> wrote:
> On 08/02/2010 08:16 PM, David Leverton wrote:
>> If so, it sounds like what you really want is per-package eclasses
>> (maybe with elibs as well to hold the non-metadata code), which
>> aren't covered by GLEP33 but ought to be easy enough to add.
>
> It's actually covered by GLEP33:
> http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring

I interpreted that more as a way to organise the global eclasses, but
yes, it could be used for per-package stuff too.  I'd still prefer to
have the eclasses next to the ebuilds they're meant to be used by, but
that's just a detail (and as I say, could easily be added to the GLEP
if anyone else wants it).

Re: [gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On 08/03/2010 12:17 AM, David Leverton wrote:
> On 2 August 2010 22:40, Matti Bickel <mabi@gentoo.org> wrote:
>> On 08/02/2010 08:16 PM, David Leverton wrote:
>>> If so, it sounds like what you really want is per-package eclasses
>>> (maybe with elibs as well to hold the non-metadata code), which
>>> aren't covered by GLEP33 but ought to be easy enough to add.
>>
>> It's actually covered by GLEP33:
>> http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring
> 
> I interpreted that more as a way to organise the global eclasses

Yes, I thought you were talking about them. Introducing eclasses into
the rest of the tree - is that possible from the implementation side?
That is, how can PMs support that w/o much hassle? Are there any speed
considerations that need to be taken into account?

I like the idea. Having dev-lang/php/php-common.eclass makes a lot more
sense then putting it into ${PORTDIR}/include/eclass.

PHP will still need global eclasses for PEAR and pecl stuff, so I like
them moving forward, too. And hiding them into
${PORTDIR}/include/eclass/php/ might be a good first step.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 318 bytes --]

On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible.

current eblits support isnt going anywhere.  so dont waste time trying to 
change code if there is no real alternative.  see Bug 327999.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible.
> 
> current eblits support isnt going anywhere.  so dont waste time trying to 
> change code if there is no real alternative.  see Bug 327999.

Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a
different issue, isn't it? I don't see how elibs are not an alternative
for eblits. What can you do with eblits you can't do with elibs?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 773 bytes --]

On Monday, August 02, 2010 17:47:01 Matti Bickel wrote:
> On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> > On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> >> I've been told that my use of eblits in dev-lang/php is something I
> >> should get rid of as soon as possible.
> > 
> > current eblits support isnt going anywhere.  so dont waste time trying to
> > change code if there is no real alternative.  see Bug 327999.
> 
> Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a
> different issue, isn't it? I don't see how elibs are not an alternative
> for eblits. What can you do with eblits you can't do with elibs?

i didnt mean to indicate that you shouldnt look at moving forward.  progress 
is a good thing after all.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

On Mon, 02 Aug 2010 23:47:01 +0200
Matti Bickel <mabi@gentoo.org> wrote:
> What can you do with eblits you can't do with elibs?

Define certain arbitrarily selected things that are legal in ebuilds
and eclasses but not elibs.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Mon, 02 Aug 2010 11:56:08 +0200
Matti Bickel <mabi@gentoo.org> wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by
> ferring: use elibs.
> 
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.

Aren't you really after per-package eclasses, not elibs? Now that
eclasses for installed packages are handled sanely, elibs are just a way
to reduce the metadata generation impact of changing a widely used
eclass, and processors are getting faster faster than the tree is
growing.

> Instead of all the backwards-compatibility issues the GLEP deals with,
> we could just sneak the implementation into EAPI4 and be done with it.

No, you can't make global scope changes just in an EAPI without
screwing up user systems. You have to do the whole "wait several years"
thing for them. If you don't want to screw things up for users, the
only way of avoiding a huge wait for all of this would be to adopt GLEP
55, and of course GLEP 55 won't ever be adopted without years of noise
anyway, so this whole discussion is purely academic.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> Aren't you really after per-package eclasses, not elibs?

Yes. I don't care whether the snippets may affect metadata. They already
don't (at one time they did, but we got warned that that's illegal -
that's why php-5.3 ebuilds have their metadata folded back into them).

>> Instead of all the backwards-compatibility issues the GLEP deals with,
>> we could just sneak the implementation into EAPI4 and be done with it.
> 
> No, you can't make global scope changes just in an EAPI without
> screwing up user systems. You have to do the whole "wait several years"
> thing for them.

Bad. So I guess it's back to ferring's "use a new directory not readable
by old PMs" idea. GLEP55++, but having to wait several months for that
and GLEP33 *on top* is not very motivation for me.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Mon, 02 Aug 2010 23:55:07 +0200
Matti Bickel <mabi@gentoo.org> wrote:
> > No, you can't make global scope changes just in an EAPI without
> > screwing up user systems. You have to do the whole "wait several
> > years" thing for them.
> 
> Bad. So I guess it's back to ferring's "use a new directory not
> readable by old PMs" idea. GLEP55++, but having to wait several
> months for that and GLEP33 *on top* is not very motivation for me.

Unlike the other ways of allowing new global scope functions, GLEP 55
doesn't require a wait, and it doesn't require mass fixing of existing
packages. That's part of the point of it. GLEP 55 can be rolled out and
used as quickly as the code to support it in Portage is unreverted.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Mon, Aug 02, 2010 at 11:55:07PM +0200, Matti Bickel wrote:
> On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> > Aren't you really after per-package eclasses, not elibs?
> 
> Yes. I don't care whether the snippets may affect metadata. They already
> don't (at one time they did, but we got warned that that's illegal -
> that's why php-5.3 ebuilds have their metadata folded back into them).
> 
> >> Instead of all the backwards-compatibility issues the GLEP deals with,
> >> we could just sneak the implementation into EAPI4 and be done with it.
> > 
> > No, you can't make global scope changes just in an EAPI without
> > screwing up user systems. You have to do the whole "wait several years"
> > thing for them.

While it's been repeated many, many time, this statement is provably 
false.  What _is_ true is that you cannot have new global scope 
functionality that influences/sets EAPI.  That is _accurate_ truth of 
the matter.

If a PM encounters an EAPI it doesn't understand/support, by 
definition the metadata it tried generating is not usable- the PM 
doesn't support that new EAPI thus it has zero clue how to 
generate/store metadata appropriately for that EAPI.

Note that since policy forbids EAPI being set in eclasses _anyways_, 
there isn't a conflict here despite ciaran's claims.

If an EAPI adds a new global function that cannot set/influence EAPI, 
PM's that don't support that EAPI will spit complaints about 'missing 
command' during sourcing- however the PM will still see the EAPI value 
is one it knows it doesn't support, and act accordingly.

Basically, the only real issue here is that PMs invalidly output 
stdout/stderr for EAPIs they don't support- this gives the perception 
that there is an issue, when in reality it's just the PM being 
slightly user unfriendly.


> Bad. So I guess it's back to ferring's "use a new directory not readable
> by old PMs" idea. GLEP55++, but having to wait several months for that
> and GLEP33 *on top* is not very motivation for me.

The reason for a new directory was to enforce a new structuring that 
was more friendly to changelogs and manifests- due to ECLASSDIR being 
documented in PMS (and annoyingly eclass-manpagers being the sole 
consumer of it) adding a new eclasses directory should require a EAPI 
bump.


As for per package eclasses, I'd personally require accessing the 
package eclass being done via a new inherit function- this avoids some 
annoying gotchas.  That said, I don't see a reason right now that it 
couldn't be added into an EAPI, per the reasons I laid out earlier in 
this email.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On 08/05/2010 05:27 AM, Brian Harring wrote:
> If a PM encounters an EAPI it doesn't understand/support, by 
> definition the metadata it tried generating is not usable- the PM 
> doesn't support that new EAPI thus it has zero clue how to 
> generate/store metadata appropriately for that EAPI.

I guess the point here is that we need a stable version of PMs for a
reasonable time before we switch tree ebuilds to it.
People will hate me if I use EAPI4 functionality in php ebuilds as soon
as councils approves EAPI4. Security might want a word with me if it's a
fast-stable security release.

But this is orthogonal to GLEP55, afaik.

>> Bad. So I guess it's back to ferring's "use a new directory not readable
>> by old PMs" idea. GLEP55++, but having to wait several months for that
>> and GLEP33 *on top* is not very motivation for me.
> 
> The reason for a new directory was to enforce a new structuring that 
> was more friendly to changelogs and manifests- due to ECLASSDIR being 
> documented in PMS (and annoyingly eclass-manpagers being the sole 
> consumer of it) adding a new eclasses directory should require a EAPI 
> bump.

I'm not going to argue that PMS doesn't seem to say anything about the
content of ECLASSDIR other than that eclasses are stored inside it.
A new dir is fine with me. Can we have that in EAPI4 or is that already
being finalized?

> As for per package eclasses, I'd personally require accessing the 
> package eclass being done via a new inherit function- this avoids some 
> annoying gotchas.  That said, I don't see a reason right now that it 
> couldn't be added into an EAPI, per the reasons I laid out earlier in 
> this email.

Okay, so how can I, as somebody not familiar with PM dev process and
roadmaps, help in getting this done?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Jeremy Olexa]

On 08/05/2010 12:22 PM, Matti Bickel wrote:

> I guess the point here is that we need a stable version of PMs for a
> reasonable time before we switch tree ebuilds to it.
> People will hate me if I use EAPI4 functionality in php ebuilds as soon
> as councils approves EAPI4. Security might want a word with me if it's a
> fast-stable security release.

People will not "hate you" - if the portage with EAPI4 is in ~arch, you 
can have PHP w/EAPI4 in ~arch, even on zero-day of release. Likewise 
with stable tree. It does not matter when council "approves" EAPI4, it 
matters when portage has the implementation and is released..

The caveat is with @system packages, especially bash/python/portage itself.

-Jeremy

[gentoo-dev] Re: RFC: Reviving GLEP33

[Duncan]

Jeremy Olexa posted on Thu, 05 Aug 2010 18:43:55 -0500 as excerpted:

> People will not "hate you" - if the portage with EAPI4 is in ~arch, you
> can have PHP w/EAPI4 in ~arch, even on zero-day of release. Likewise
> with stable tree. It does not matter when council "approves" EAPI4, it
> matters when portage has the implementation and is released..

Isn't it /both/?  IOW, just because portage implements it, doesn't mean 
it's usable in-tree, if it's not part of an approved EAPI.  Similarly, 
approval before released support again doesn't mean it's allowed in-tree.  
Only with both is it then allowed.

Leastwise, that was my read of the council decision back then.

But zero-day, yes, provided it's both approved and in-portage at the same 
level (~arch or stable).

> The caveat is with @system packages, especially bash/python/portage
> itself.

Again, yes.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

On Thu, Aug 05, 2010 at 07:22:20PM +0200, Matti Bickel wrote:
> On 08/05/2010 05:27 AM, Brian Harring wrote:
> > If a PM encounters an EAPI it doesn't understand/support, by 
> > definition the metadata it tried generating is not usable- the PM 
> > doesn't support that new EAPI thus it has zero clue how to 
> > generate/store metadata appropriately for that EAPI.
> 
> I guess the point here is that we need a stable version of PMs for a
> reasonable time before we switch tree ebuilds to it.
> People will hate me if I use EAPI4 functionality in php ebuilds as soon
> as councils approves EAPI4. Security might want a word with me if it's a
> fast-stable security release.
> 
> But this is orthogonal to GLEP55, afaik.

Glep55 suffers the same, rather than being orthogonal.

Alternatively phrased, you can't start using a new feature until 
support is out there.  So after an EAPI is defined, you've got a month 
or so realistically, and that's assuming portage/friends support the 
EAPI at the time it's minted as official.


> >> Bad. So I guess it's back to ferring's "use a new directory not readable
> >> by old PMs" idea. GLEP55++, but having to wait several months for that
> >> and GLEP33 *on top* is not very motivation for me.
> > 
> > The reason for a new directory was to enforce a new structuring that 
> > was more friendly to changelogs and manifests- due to ECLASSDIR being 
> > documented in PMS (and annoyingly eclass-manpagers being the sole 
> > consumer of it) adding a new eclasses directory should require a EAPI 
> > bump.
> 
> I'm not going to argue that PMS doesn't seem to say anything about the
> content of ECLASSDIR other than that eclasses are stored inside it.
> A new dir is fine with me. Can we have that in EAPI4 or is that already
> being finalized?

EAPI4 is a bit up in the air from where I'm sitting.  Write up 
a proposal (or clean up the g33 glep) and push it- even if you miss 
eapi4 (doubtful), it'll be in the next eapi.


> > As for per package eclasses, I'd personally require accessing the 
> > package eclass being done via a new inherit function- this avoids some 
> > annoying gotchas.  That said, I don't see a reason right now that it 
> > couldn't be added into an EAPI, per the reasons I laid out earlier in 
> > this email.
> 
> Okay, so how can I, as somebody not familiar with PM dev process and
> roadmaps, help in getting this done?

I'd suggest roughly the following-

pkg-inherit ['the per pkg-name'] ; specifically, pkg-inherit 
automatically grabs some commonly named package eclass- or you can 
optionally override the per package eclass to use.

The reason for the option is in transitioning away from an old eclass 
implementation, or having an eclass per major version (assuming the 
major versions warrant a seperate eclass).

Note that '/' and friends should be banned from the invocation, to 
prevent a pkg-inherit from trying to reach into another packages 
eclasses.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[David Leverton]

On 5 August 2010 04:27, Brian Harring <ferringb@gmail.com> wrote:
> If an EAPI adds a new global function that cannot set/influence EAPI,
> PM's that don't support that EAPI will spit complaints about 'missing
> command' during sourcing- however the PM will still see the EAPI value
> is one it knows it doesn't support, and act accordingly.

You're suggesting a system based around ebuilds running commands that
don't exist and ignoring the errors, which is a pretty blatant hack.
While I don't think it's /absolutely/ out of the question, as I said
earlier, I can see why some people would exclude it from consideration
entirely.

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

On Fri, Aug 06, 2010 at 05:15:15PM +0100, David Leverton wrote:
> On 5 August 2010 04:27, Brian Harring <ferringb@gmail.com> wrote:
> > If an EAPI adds a new global function that cannot set/influence EAPI,
> > PM's that don't support that EAPI will spit complaints about 'missing
> > command' during sourcing- however the PM will still see the EAPI value
> > is one it knows it doesn't support, and act accordingly.
> 
> You're suggesting a system based around ebuilds running commands that
> don't exist and ignoring the errors, which is a pretty blatant hack.

It's called forwards compatibility, and is basically no different than 
type -p usage- the sole diff is that in ebuild usage since you're just 
pulling metadata as the first step, the existance check isn't needed 
since that functionality can't influence/set EAPI.  If you don't 
support the EAPI result, complaining to the user about the steps 
getting there is misinformative at best.  If you do support that EAPI, 
than bitch at the user with the errors.

As for 'blatant hack', if you've got no users nor preexisting ebuild 
data, you can design whatever you want- it's quite easy to call things 
blatant hacks if you can design things from scratch and not worry 
about compatibility.  This is a form of armchair quarterbacking.

EAPI did not have that luxury however, thus a pragmatic solution was 
choosen.  I've heard a lot of bitching from various folk about EAPI 
over the years, but the fact is even with it's flaws (both in 
process, people involved, and in original constraints) it still has 
been rolling changes out- all the while without requiring people to 
rewrite ebuilds from scratch, or continually track an unversioned 
format that changes semi-monthly.

It'd be nice if people were to remember that rather than spending 
their time bitching about it.  Hindsight, I'd have done a few things 
differently, but that's the nature of hindsight- specifically I 
would've used an eapi function rather than var.


> While I don't think it's /absolutely/ out of the question, as I said
> earlier, I can see why some people would exclude it from consideration
> entirely.

Whether said people like it or not, it was a known decision at the 
time of creation- including the scenario under discussion.  One thing 
you'll note about my posts is that I'll list out what is possible, 
and state what should/shouldn't be done.  Just because I personally 
think something is complete shit doesn't mean I go telling folk it's 
impossible.  There's a difference between opinion and fact- you're 
excusing opinion stated as fact, which is not correct.  Fact is, this 
technique does work even if certain folk have another approach they 
want instead.

Either way, this trick does work, although PM's could stand some 
tweaking in their stdout/stderr outputting to make it a bit more user 
friendly, so g33 can be ironed out.

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

On Fri, 6 Aug 2010 10:27:32 -0700
Brian Harring <ferringb@gmail.com> wrote:
> As for 'blatant hack', if you've got no users nor preexisting ebuild 
> data, you can design whatever you want- it's quite easy to call
> things blatant hacks if you can design things from scratch and not
> worry about compatibility.  This is a form of armchair quarterbacking.

No it isn't, since we've proposed a working alternative that doesn't
have any of the defects that EAPI in its current form does.

> EAPI did not have that luxury however, thus a pragmatic solution was 
> choosen.  I've heard a lot of bitching from various folk about EAPI 
> over the years, but the fact is even with it's flaws (both in 
> process, people involved, and in original constraints) it still has 
> been rolling changes out- all the while without requiring people to 
> rewrite ebuilds from scratch, or continually track an unversioned 
> format that changes semi-monthly.

You appear to be confusing "providing a better replacement that we can
use immediately that doesn't have any of these problems" with
"bitching".

> It'd be nice if people were to remember that rather than spending 
> their time bitching about it.  Hindsight, I'd have done a few things 
> differently, but that's the nature of hindsight- specifically I 
> would've used an eapi function rather than var.

That's ok. We can migrate to an even better solution now.

> Whether said people like it or not, it was a known decision at the 
> time of creation- including the scenario under discussion.  One thing 
> you'll note about my posts is that I'll list out what is possible, 
> and state what should/shouldn't be done.  Just because I personally 
> think something is complete shit doesn't mean I go telling folk it's 
> impossible.  There's a difference between opinion and fact- you're 
> excusing opinion stated as fact, which is not correct.  Fact is, this 
> technique does work even if certain folk have another approach they 
> want instead.

The *fact* is, you can't use new version formats with any of your
proposals, and using new global scope functionality or new bash
functionality introduces all kinds of nasty difficulties and arbitrary
restrictions of which developers have to be intimately aware.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

On Fri, Aug 06, 2010 at 06:48:31PM +0100, Ciaran McCreesh wrote:
> On Fri, 6 Aug 2010 10:27:32 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > As for 'blatant hack', if you've got no users nor preexisting ebuild 
> > data, you can design whatever you want- it's quite easy to call
> > things blatant hacks if you can design things from scratch and not
> > worry about compatibility.  This is a form of armchair quarterbacking.
> 
> No it isn't, since we've proposed a working alternative that doesn't
> have any of the defects that EAPI in its current form does.
<snip>
> You appear to be confusing "providing a better replacement that we can
> use immediately that doesn't have any of these problems" with
> "bitching".
<snip>
> That's ok. We can migrate to an even better solution now.

And by "right now", I assume you meant to say "minimally a year down 
the line after a portage is stabled supporting g55 semantics and 
resolving any breakage it's usage induces".  You know, the same issue 
EAPI itself had to go through to ensure that people had a reasonable 
chance of getting an appropriate error message and support being in 
place.

Accuracy in details is very useful, including stating the full picture 
rather than just the parts you think sell your particular view.


> The *fact* is, you can't use new version formats with any of your
> proposals,

New version formats aren't magically usable the moment g55 lands.  At 
the very least you're forgetting about bundled glsa's and their 
knowledge of atom formats.

Suppose the next comment will be "they suck, throw them out", but so 
it goes.

Realistically, 'the fact is' that a specific scm tag is preferable to 
-9999.  The reality is that people and the tools have been working 
around it without huge issues for a long while.

Would it be nice having some -scm tag?  Sure.  Is it worth the 
disruption impementing it, and it's dependencies requires?  That 
arguement you've still not managed to convince people of.


> and using new global scope functionality or new bash
> functionality introduces all kinds of nasty difficulties and arbitrary
> restrictions of which developers have to be intimately aware.

The restrictions are "no new global functionality can set or influence 
EAPI".  Basically the same restriction you forced on eclasses.  It's 
nasty and arbitrary when I state it, but some how it is sane when you 
propose it the same thing?


The thing you're ignoring out of this g55 idiocy is that people don't 
particularly seem to want it.  There has been an extremely vocal 
subgroup of paludis/exherbo devs pushing for it while everyone else 
seems to have less than an interest in it.  That's generalizing a bit, 
but is reasonably accurate.

Pretty much, scream all you want, if people don't like it it's not 
going to go anywhere.  So... keep fighting windmills, or do something 
useful and use what is available to you (existing EAPI semantics).

_EITHER WAY_, rather than having g33 get beat down for unrelated 
reasons by people screaming they want their pony/g55, g33 can proceed 
despite claims to the contrary, and it doesn't require g55 as 
ciaran/crew have claimed.

Split a thread if you really want to rehash g55 also, rather than the 
thread jacking that is underway.

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

On Fri, 6 Aug 2010 11:18:46 -0700
Brian Harring <ferringb@gmail.com> wrote:
> And by "right now", I assume you meant to say "minimally a year down 
> the line after a portage is stabled supporting g55 semantics and 
> resolving any breakage it's usage induces".  You know, the same issue 
> EAPI itself had to go through to ensure that people had a reasonable 
> chance of getting an appropriate error message and support being in 
> place.

Uh, no, since GLEP 55 doesn't need users to be using a newer Portage.
That is one of the many ways in which it is a much better solution.

> New version formats aren't magically usable the moment g55 lands.  At 
> the very least you're forgetting about bundled glsa's and their 
> knowledge of atom formats.
> 
> Suppose the next comment will be "they suck, throw them out", but so 
> it goes.

No, the fix is to give them EAPI suffixes too.

> Realistically, 'the fact is' that a specific scm tag is preferable to 
> -9999.  The reality is that people and the tools have been working 
> around it without huge issues for a long while.
> 
> Would it be nice having some -scm tag?  Sure.  Is it worth the 
> disruption impementing it, and it's dependencies requires?  That 
> arguement you've still not managed to convince people of.

...and 1.2-3 and 1.2-alpha3 style versions, and so on.

Remember, it's only a disruption to implement it without GLEP 55.

> The restrictions are "no new global functionality can set or
> influence EAPI".  Basically the same restriction you forced on
> eclasses.  It's nasty and arbitrary when I state it, but some how it
> is sane when you propose it the same thing?

No, they're not. The restrictions are "no changes that will make older
package managers not realise that the EAPI was supposed to have been set
to something else". That's not the same thing at all, especially on the
"using new Bash syntax" front, and the very fact that you missed that
point just goes to illustrate the difficulties involved.

> The thing you're ignoring out of this g55 idiocy is that people don't 
> particularly seem to want it.  There has been an extremely vocal 
> subgroup of paludis/exherbo devs pushing for it while everyone else 
> seems to have less than an interest in it.  That's generalizing a
> bit, but is reasonably accurate.

Uh, no. Plenty of people want it. There has been an extremely vocal
subgroup of people who will yell at anything they think is connected to
the 'wrong people' pushing against it, thus making everyone else suffer.

> _EITHER WAY_, rather than having g33 get beat down for unrelated 
> reasons by people screaming they want their pony/g55, g33 can proceed 
> despite claims to the contrary, and it doesn't require g55 as 
> ciaran/crew have claimed.

But no-one except you wants GLEP 33. What people want is per-package
eclasses *without* all the arbitrary restrictions in GLEP 33.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 6519 bytes --]

On Fri, Aug 06, 2010 at 07:34:09PM +0100, Ciaran McCreesh wrote:
> On Fri, 6 Aug 2010 11:18:46 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > And by "right now", I assume you meant to say "minimally a year down 
> > the line after a portage is stabled supporting g55 semantics and 
> > resolving any breakage it's usage induces".  You know, the same issue 
> > EAPI itself had to go through to ensure that people had a reasonable 
> > chance of getting an appropriate error message and support being in 
> > place.
> 
> Uh, no, since GLEP 55 doesn't need users to be using a newer Portage.
> That is one of the many ways in which it is a much better solution.

Currently, a PM that doesn't support EAPI4 will tell you "there is a 
version available, but I don't support this- upgrade me".  Versus 
current PM's + g55 == "I see no version".

*addressing* that would be useful, rather than staying in g55 
salesman mode.  Like it or not, you switch out the compatibility 
mechanisms there are delays that go with it while waiting on the 
implementations to propagate.

Now if your solution is "they don't see the version till they 
upgrade", fine, at least it's accurate and it's stated.  This is a 
fair bit more useful than "there is no issue and it solves world 
hunger in it's spare time".  Grok?


> > New version formats aren't magically usable the moment g55 lands.  At 
> > the very least you're forgetting about bundled glsa's and their 
> > knowledge of atom formats.
> > 
> > Suppose the next comment will be "they suck, throw them out", but so 
> > it goes.
> 
> No, the fix is to give them EAPI suffixes too.

You checked existing glsa parser to see what they'll do if they get 
new attributes/tags jammed into the format?

Verifying they'll actually ignore the extension is needed rather than 
hand wavey crap.  I'd hope they don't go boom, but there have been 
issues in the past of this sort.

News items are another one that come to mind.  Last glance, there 
wasn't a tag that was jammed into it stating "to even interpret this 
atom you need to be at least eapi foo"- glep42 surely doesn't cover 
it.

Meaning that a proper implementation will parse it, and quite likely 
go boom.  Meaning either those new version schemes you want can't be 
used for at least a year in news items.

EAPI suffixes addresses one problem.  Pretending it solves all is 
invalid however- GLSA's at the very least probably will have problems, 
NEWS items most definitely will.


> > The restrictions are "no new global functionality can set or
> > influence EAPI".  Basically the same restriction you forced on
> > eclasses.  It's nasty and arbitrary when I state it, but some how it
> > is sane when you propose it the same thing?
> 
> No, they're not. The restrictions are "no changes that will make older
> package managers not realise that the EAPI was supposed to have been set
> to something else". That's not the same thing at all, especially on the
> "using new Bash syntax" front, and the very fact that you missed that
> point just goes to illustrate the difficulties involved.

My stating of restrictions is actually the accurate one.  If the rules 
were what you stated, eclasses would be allowed to set EAPI.

Point is, ebuild's set the EAPI themselves.  Even your g55 proposal 
requires this explicitly via the file naming.

EAPI in the ebuild combined w/ global functionality never being 
allowed to screw with EAPI means global scope functionality that 
doesn't set/influence EAPI is entirely valid.

If you're going to claim otherwise, provide an example of per pkg 
eclasses that fit the requirements stated above that would result in 
an invalid EAPI.  Take an existing ebuild out of the tree to prove 
it.

As for bash syntax, that's wholy unrelated to g33.  g33, like normal 
eclasses, is bound by bash syntax requirements of the current eapi 
docs.

Now removing that limitation might be nice, but it's not core to 
providing the functionality- as such lay off the bash crap, it's a 
selling point of g55, it's orthogonal to g33 however.


> > The thing you're ignoring out of this g55 idiocy is that people don't 
> > particularly seem to want it.  There has been an extremely vocal 
> > subgroup of paludis/exherbo devs pushing for it while everyone else 
> > seems to have less than an interest in it.  That's generalizing a
> > bit, but is reasonably accurate.
> 
> Uh, no. Plenty of people want it. There has been an extremely vocal
> subgroup of people who will yell at anything they think is connected to
> the 'wrong people' pushing against it, thus making everyone else suffer.

And plenty of people hate it too, for the abuse of extensions.  

The knee jerk claim that the only people who oppose this glep are 
anti-paludis/exherbo fan boys is the _same_ *bullshit* black/white 
nonsense y'all railed about it in a seperate part of this thread.

Occusing others of fanboy idiocy while pulling the same to excuse away 
peoples complaints with the glep is hypocritical bullshit.  It's very, 
very tiring, and there are groups on boths sides who pull that shit.

Simply put, behaviour of this sort results in people ignoring y'all.  
Frankly with good reason- may have technical points, but the 
signal to bullshit ratio is far too high with behaviour of that sort.


> > _EITHER WAY_, rather than having g33 get beat down for unrelated 
> > reasons by people screaming they want their pony/g55, g33 can proceed 
> > despite claims to the contrary, and it doesn't require g55 as 
> > ciaran/crew have claimed.
> 
> But no-one except you wants GLEP 33. What people want is per-package
> eclasses *without* all the arbitrary restrictions in GLEP 33.

Considering g33 in it's current form doesn't even lay out specifics of 
per-package eclasses (mabi is working up a glep on that), this is a 
bit of a bullshit statement.

The sole restriction that has been stated thus far for discussion of 
per package eclasses is "no EAPI setting in the eclass".  Labeling 
that an arbitrary restriction when _you_ pushed the same into global 
eclasses is at best hypocritical, at worst flat out lieing.

Fact is, people want per package eclasses.
Additional fact is that both forms of can't screw with EAPI.
Final fact is that g55 isn't required for g33- and until you come up 
with actual, testable examples, I'm done correcting your 
misstatements.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ben de Groot]

On 7 August 2010 02:18, Brian Harring <ferringb@gmail.com> wrote:
> The thing you're ignoring out of this g55 idiocy is that people don't
> particularly seem to want it.  There has been an extremely vocal
> subgroup of paludis/exherbo devs pushing for it while everyone else
> seems to have less than an interest in it.  That's generalizing a bit,
> but is reasonably accurate.

Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
and stop trying to interfere with Gentoo. It is time the council puts
a definite stop to GLEP 55.

> _EITHER WAY_, rather than having g33 get beat down for unrelated
> reasons by people screaming they want their pony/g55, g33 can proceed
> despite claims to the contrary, and it doesn't require g55 as
> ciaran/crew have claimed.

I for one am a strong supporter of GLEP 33. I believe it is one of the
most promising ways to move forward. And I hope the council decides to
get behind this.

Cheers,
Ben

Re: [gentoo-dev] RFC: Reviving GLEP33

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Thu, 12 Aug 2010 15:51:54 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
> and stop trying to interfere with Gentoo. It is time the council puts
> a definite stop to GLEP 55.

GLEP:	55
Author:	Piotr Jaroszyński <peper at gentoo.org>
                                       ^
                                       |
Bad troll! No cookie! -----------------+

And on top of that:

20090514:

    After quite a bit of confusion in the voting(people
    changing their votes), a tie(3-3) vote was reached.
    Therefore, no decision was reached. This vote will be
    brought up again next meeting so that the tie can be
    broken(hopefully with everyone present).

20090528:

    The council voted on whether they recognized the problem
    that GLEP 55 is attempting to solve is real. The vote was
    affirmative in recognition of the problem with two
    abstentions(leio and ulm).

I wasn't aware that so many Gentoo developers and Council members were
secretly actually Exherbo developers. Do you have a list somewhere that
I can consult to find out just who all these undercover agents are?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 1628 bytes --]

Ben de Groot <yngwin@gentoo.org> said:
> On 7 August 2010 02:18, Brian Harring <ferringb@gmail.com> wrote:
> > The thing you're ignoring out of this g55 idiocy is that people don't
> > particularly seem to want it.  There has been an extremely vocal
> > subgroup of paludis/exherbo devs pushing for it while everyone else
> > seems to have less than an interest in it.  That's generalizing a
> > bit, but is reasonably accurate.
> 
> Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
> and stop trying to interfere with Gentoo. It is time the council puts
> a definite stop to GLEP 55.

if the council should stop anything, then rude behavior like you have 
shown. I am personally much in favor for GLEP55, as it solves a technical 
problem that keeps coming up and have no association with Exherbo at all.

If you want to constructively contribute to Gentoo, i'd hope you 
reconsider a message like the above before sending it next time.


> 
> > _EITHER WAY_, rather than having g33 get beat down for unrelated
> > reasons by people screaming they want their pony/g55, g33 can proceed
> > despite claims to the contrary, and it doesn't require g55 as
> > ciaran/crew have claimed.
> 
> I for one am a strong supporter of GLEP 33. I believe it is one of the
> most promising ways to move forward. And I hope the council decides to
> get behind this.

I for one am a strong supporter of GLEP 55. I believe it is one of the
most promising ways to move forward. And I hope the council decides to
get behind this.

I also support the aims of GLEP33.

> 
> Cheers,
> Ben


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: Reviving GLEP33

[David Leverton]

On 12 August 2010 08:51, Ben de Groot <yngwin@gentoo.org> wrote:
> Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
> and stop trying to interfere with Gentoo. It is time the council puts
> a definite stop to GLEP 55.

I've already discussed this with you, but it seems you still don't get
it.  People are not defined as "Gentoo people" or "Exherbo people".  I
can't speak for anyone else, but I am a sentient being with enough
mental capacity to be interested in more than one thing at once - in
other words, being an Exherbo developer doesn't in any way interfere
with wanting to see Gentoo improve.  There is no activity from Exherbo
trying to push anything on Gentoo, there is only Gentoo users
contributing ideas towards developing the distribution.