Mailing List Archive

Jeremy Olexa wrote:
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.

YES!! Please.

Ben

Jeremy Olexa wrote:
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.

+1

Dne středa 12 Srpen 2009 19:58:05 Jeremy Olexa napsal(a):
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.
>
> This seems like progress to me. Often, developers are complaining that
> they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
> the only time we can bump EAPI syntax in profiles is upon a new
> directory creation, this seems like a good time to me. The new
> profiles are still in flux until the official stages/cd's are
> produced.
>
> Also, another good reason is: "why not?" I don't think any Gentoo user
> can avoid EAPI-2 up til now anyway.
>
> Any comments? No comments means it will be decided off-list.
> Timeframe: 1 week from now.
> -Jeremy
Agreed. This is great idea.
Also we should allow the stuff as directory thingus (portage already handles
it right).
package.mask/koffice-2
package.mask/live-gnome
....

Tomas

On Wed, 12 Aug 2009 20:41:30 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> Also we should allow the stuff as directory thingus (portage already
> handles it right).

That's a seperate thing that needs EAPI control. You'll need to propose
it for EAPI 4 if you want that.

--
Ciaran McCreesh

2009-08-12 20:41:30 Tomáš Chvátal napisał(a):
> Dne středa 12 Srpen 2009 19:58:05 Jeremy Olexa napsal(a):
> > I am suggesting that the new 10.0 profiles be marked as EAPI-2
> > compliant. This involves setting the content of the 'eapi' file to "2"
> > and bumping up the required portage version.
> >
> > This seems like progress to me. Often, developers are complaining that
> > they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
> > the only time we can bump EAPI syntax in profiles is upon a new
> > directory creation, this seems like a good time to me. The new
> > profiles are still in flux until the official stages/cd's are
> > produced.
> >
> > Also, another good reason is: "why not?" I don't think any Gentoo user
> > can avoid EAPI-2 up til now anyway.
> >
> > Any comments? No comments means it will be decided off-list.
> > Timeframe: 1 week from now.
> > -Jeremy
> Agreed. This is great idea.
> Also we should allow the stuff as directory thingus (portage already handles
> it right).
> package.mask/koffice-2
> package.mask/live-gnome
> ....

+1.

--
Arfrever Frehtes Taifersar Arahesis

On Wed, 12 Aug 2009 19:46:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
>
> That's a seperate thing that needs EAPI control. You'll need to propose
> it for EAPI 4 if you want that.

Why is that (seriously curious, not disagreeing)? Portage has supported this
for quite a while now. Does the current PMS disallow it?

What I've really wanted for a long time is different package.mask files for
different types of masks. eg.

package.mask/broken.mask (qa.mask?)
package.mask/removal.mask
package.mask/security.mask
package.mask/testing.mask
etc.

If this requires a EAPI change, let me be the first to request it for EAPI
4. ;)

--
gcc-porting, Character is what you are in the dark.
treecleaner,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> >
> > That's a seperate thing that needs EAPI control. You'll need to propose
> > it for EAPI 4 if you want that.
>
> Why is that (seriously curious, not disagreeing)? Portage has supported this
> for quite a while now. Does the current PMS disallow it?
>
> What I've really wanted for a long time is different package.mask files for
> different types of masks. eg.
>
> package.mask/broken.mask (qa.mask?)
> package.mask/removal.mask
> package.mask/security.mask
> package.mask/testing.mask

To avoid collision with the current package.mask I'd prefer
package.mask.d/ for the directory. Also makes the transition easy since
we can generate package.mask out of the files in package.mask.d/.

--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

On Wed, 12 Aug 2009 23:55:22 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> > That's a seperate thing that needs EAPI control. You'll need to
> > propose it for EAPI 4 if you want that.
>
> Why is that (seriously curious, not disagreeing)? Portage has
> supported this for quite a while now. Does the current PMS disallow
> it?

Yup. We based the PMS wording upon the Portage documentation and the
commit message that introduced the feature, both of which explicitly
say it's only for /etc/portage/ use, not tree use. Portage's support
for directories like that in the tree is an undocumented fluke caused
by using the same code for user and tree configuration parsing without
adding extra strictness checks for the tree.

--
Ciaran McCreesh

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

>
> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
>
> That's a seperate thing that needs EAPI control. You'll need to propose
> it for EAPI 4 if you want that.
>

Except this "stuff as directory" was pre-EAPI and thus the PMS should have
captured that as EAPI-1
Ergo PMS is wrong and needs to be updated to refect reality

but back on topic
++

On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage
> > > already handles it right).
> >
> > That's a seperate thing that needs EAPI control. You'll need to
> > propose it for EAPI 4 if you want that.
>
> Except this "stuff as directory" was pre-EAPI and thus the PMS should
> have captured that as EAPI-1
> Ergo PMS is wrong and needs to be updated to refect reality

PMS accurately reflects the Portage documentation and the commit
message that introduced the feature -- it's purely for use
in /etc/portage/, which is beyond the scope of PMS.

It is not the business of PMS to enforce undocumented features that
Portage supports only by accident and that aren't used in the tree.

--
Ciaran McCreesh

On Thu, Aug 13, 2009 at 4:05 PM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.
>

I completely agree with this. A script similar to metadata.xml ->
use.local.desc can be run on it (with more frequency), and eventually
(EAPI=4?) we can move away from the file-based one.

--
~Nirbheek Chauhan

GNOME Team, Gentoo

On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote:
> Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> > On Wed, 12 Aug 2009 19:46:56 +0100
> >
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > >
> > > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage already
> > > > handles it right).
> > >
> > > That's a seperate thing that needs EAPI control. You'll need to propose
> > > it for EAPI 4 if you want that.
> >
> > Why is that (seriously curious, not disagreeing)? Portage has supported
> > this for quite a while now. Does the current PMS disallow it?
> >
> > What I've really wanted for a long time is different package.mask files
> > for different types of masks. eg.
> >
> > package.mask/broken.mask (qa.mask?)
> > package.mask/removal.mask
> > package.mask/security.mask
> > package.mask/testing.mask
>
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.

package.mask.d being directory and not used internally by PM - so being just a
convention (which may be used for manually or scripted generation of resulting
package.mask as dev-zero proposed- it's now utilized in kde-testing overlay
because package.mask dir used to cause paludis crashes) can be implemented
just now with no PMS changes (since PM is supposed to ignore unknown
files/directories in there?).

I'd suggest allowing package.mask as either directory or file though, no need
for entities multiplying... besides the reference implementation in already
there for ages.

--
regards
MM

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

>
> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe <at> soon.com> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage
> > > > already handles it right).
> > >
> > > That's a seperate thing that needs EAPI control. You'll need to
> > > propose it for EAPI 4 if you want that.
> >
> > Except this "stuff as directory" was pre-EAPI and thus the PMS should
> > have captured that as EAPI-1
> > Ergo PMS is wrong and needs to be updated to refect reality
>
> PMS accurately reflects the Portage documentation and the commit
> message that introduced the feature -- it's purely for use
> in /etc/portage/, which is beyond the scope of PMS.
>
> It is not the business of PMS to enforce undocumented features that
> Portage supports only by accident and that aren't used in the tree.
>

PMS doesn't depict just what portage should do, just what ebuild's in the main
tree are to expect.
This is a good feature (intentional or not) of portage and is already finding
usage in overlays.

Sure for such a feature to make it into the main tree EAPI it, but as it stands
its fine

On Thu, 13 Aug 2009 17:32:56 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > It is not the business of PMS to enforce undocumented features that
> > Portage supports only by accident and that aren't used in the tree.
>
> PMS doesn't depict just what portage should do, just what ebuild's in
> the main tree are to expect.

PMS documents what ebuilds may or may not rely upon from the package
manager. PMS, like the Portage document, says that package.mask is a
file.

> This is a good feature (intentional or not) of portage and is already
> finding usage in overlays.

And it shouldn't be until it's gone through the proper process to
become a documented, controlled feature rather than an accident people
are exploiting.

Seriously, this isn't difficult to do. I get the impression people are
only trying to avoid doing it properly here so they can establish a
precedent of not doing things properly...

--
Ciaran McCreesh

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:
> PMS documents what ebuilds may or may not rely upon from the package
> manager. PMS, like the Portage document, says that package.mask is a
> file.

And main tree ebuild can rely on that. There are no directory-based
package.mask in the main portage tree


> And it shouldn't be until it's gone through the proper process to
> become a documented, controlled feature rather than an accident people
> are exploiting.
>
> Seriously, this isn't difficult to do. I get the impression people are
> only trying to avoid doing it properly here so they can establish a
> precedent of not doing things properly...
>

And if a developer would like to have it present in the main tree, sure push
for an EAPI for it to be available in the main tree. But as a feature that
portage has that overlays can use it is useful.
Ebuilds in the main tree can still exist safe in the knowledge they won't
have this

On Thu, 13 Aug 2009 18:06:04 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > And it shouldn't be until it's gone through the proper process to
> > become a documented, controlled feature rather than an accident
> > people are exploiting.
> >
> > Seriously, this isn't difficult to do. I get the impression people
> > are only trying to avoid doing it properly here so they can
> > establish a precedent of not doing things properly...
>
> And if a developer would like to have it present in the main tree,
> sure push for an EAPI for it to be available in the main tree.

Uh, yes, and that's what was being discussed before you jumped in and
claimed that PMS should support it already.

> But as a feature that portage has that overlays can use it is useful.

Not if those overlays want to claim any degree of PMS compliance. I'll
remind you that not following PMS and instead relying upon flukes in
Portage behaviour means your overlay can stop working at any moment and
with no warning. It also means your overlay will only be usable with
Portage, which won't sit very well with users of the dozen or more
other tools that work with ebuilds and repositories.

--
Ciaran McCreesh

On Thu, 13 Aug 2009 19:22:16 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> > PMS accurately reflects the Portage documentation and the commit
> > message that introduced the feature -- it's purely for use
> > in /etc/portage/, which is beyond the scope of PMS.
> >
> If it's pre-EAPI it's part of EAPI '0'. That you neglected to
> document it, for whatever reason, is irrelevant.

No, it's not part of EAPI 0. It's an accident. If you'd like another
example of an accident, Portage won't complain if you stick garbage in
certain metadata keys; this does not mean PMS should say that it's
legal to put garbage in metadata keys.

> > It is not the business of PMS to enforce undocumented features
> It's not undocumented, as you just pointed out above.

Using it in the tree is undocumented. Using it in user configuration is
beyond the scope of PMS.

> > that Portage supports only by accident
> Oh, so now you know the minds of the portage developers?

Yes. I know that they said when adding the directory feature that it
was for use in user configuration files. That's what the commit message
said, and that's what the documentation patch said. The documentation
change explicitly only allowed the feature in user configuration, not
the tree.

Had the feature intended to be tree-usable, the documentation change
would have said so.

> I'd like to present an alternative viewpoint: portage developers are
> happy to work to PMS, since it has utility for users. But ultimately,
> they're not that bothered about pushing for new things, since the
> process means dealing with you; adding features for portage only and
> leaving it up to the wider community to push for them in EAPIs is an
> awful lot less hassle.

Even a casual look at EAPI 3 will show that that is nonsense. But then,
you already know that from the previous times that claim has been made
and refuted.

> > and that aren't used in the tree.
>
> Circular argument, don't you think? It's not in-tree so we won't put
> it in PMS. It's not in PMS, so it's not allowed in-tree.

That's only a circular argument if you snip out the rest of the
sentence.

> I'd like to ask the Council to consider whether EAPI development has
> not in fact supplanted a large part of the GLEP process (specifically
> the technical aspects to do with ebuild development.) As such,
> insisting on all discussion on bugzilla is in fact a subversion of
> the original process that people have agreed upon.

Moving the discussion to bugzilla was the Council's decision, not mine.

--
Ciaran McCreesh

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe@soon.com> wrote:
>> > On Wed, 12 Aug 2009 20:41:30 +0200
>> > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
>> > > Also we should allow the stuff as directory thingus (portage
>> > > already handles it right).
>> >
>> > That's a seperate thing that needs EAPI control. You'll need to
>> > propose it for EAPI 4 if you want that.
>>
>> Except this "stuff as directory" was pre-EAPI and thus the PMS should
>> have captured that as EAPI-1
>> Ergo PMS is wrong and needs to be updated to refect reality
>
> PMS accurately reflects the Portage documentation and the commit
> message that introduced the feature -- it's purely for use
> in /etc/portage/, which is beyond the scope of PMS.
>
If it's pre-EAPI it's part of EAPI '0'. That you neglected to document it,
for whatever reason, is irrelevant.

> It is not the business of PMS to enforce undocumented features
It's not undocumented, as you just pointed out above.

> that Portage supports only by accident
Oh, so now you know the minds of the portage developers?

I'd like to present an alternative viewpoint: portage developers are happy
to work to PMS, since it has utility for users. But ultimately, they're not
that bothered about pushing for new things, since the process means dealing
with you; adding features for portage only and leaving it up to the wider
community to push for them in EAPIs is an awful lot less hassle.

> and that aren't used in the tree.
>
Circular argument, don't you think? It's not in-tree so we won't put it in
PMS. It's not in PMS, so it's not allowed in-tree.

And don't forget, we have to "claim PMS compliance" to which you are the
gatekeeper.

I'd like to ask the Council to consider whether EAPI development has not in
fact supplanted a large part of the GLEP process (specifically the
technical aspects to do with ebuild development.) As such, insisting on all
discussion on bugzilla is in fact a subversion of the original process that
people have agreed upon.

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

On Thu, 13 Aug 2009 13:29:04 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Aug 2009 23:55:22 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > > That's a seperate thing that needs EAPI control. You'll need to
> > > propose it for EAPI 4 if you want that.
> >
> > Why is that (seriously curious, not disagreeing)? Portage has
> > supported this for quite a while now. Does the current PMS disallow
> > it?
>
> Yup. We based the PMS wording upon the Portage documentation and the
> commit message that introduced the feature, both of which explicitly
> say it's only for /etc/portage/ use, not tree use. Portage's support
> for directories like that in the tree is an undocumented fluke caused
> by using the same code for user and tree configuration parsing without
> adding extra strictness checks for the tree.

Alright, thanks.


--
gcc-porting, Character is what you are in the dark.
treecleaner,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 19:22:16 +0100
> Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
>> > PMS accurately reflects the Portage documentation and the commit
>> > message that introduced the feature -- it's purely for use
>> > in /etc/portage/, which is beyond the scope of PMS.
>> >
>> If it's pre-EAPI it's part of EAPI '0'. That you neglected to
>> document it, for whatever reason, is irrelevant.
>
> No, it's not part of EAPI 0.
If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is
flexible, presumably to avoid this kind of runaround.

> It's an accident. If you'd like another
> example of an accident, Portage won't complain if you stick garbage in
> certain metadata keys; this does not mean PMS should say that it's
> legal to put garbage in metadata keys.
>
That's irrelevant and you know it, apart from being one of your usual
political digs at portage.

>> > It is not the business of PMS to enforce undocumented features
>> It's not undocumented, as you just pointed out above.
>
> Using it in the tree is undocumented.
But it's not an "undocumented feature" is it?

> Using it in user configuration is beyond the scope of PMS.
Define 'user'

>> > that Portage supports only by accident
>> Oh, so now you know the minds of the portage developers?
>
> Yes.
No, you clearly do not, as this shows:

> I know that they said when adding the directory feature that it
> was for use in user configuration files. That's what the commit message
> said, and that's what the documentation patch said. The documentation
> change explicitly only allowed the feature in user configuration, not
> the tree.
>
> Had the feature intended to be tree-usable, the documentation change
> would have said so.
>
Thanks for explaining what "the Portage documentation and the commit
message" means. And yeah, you can read it. Well done. It *does not* mean you
know what future directions might have been envisaged.

<snip>
>> > and that aren't used in the tree.
>>
>> Circular argument, don't you think? It's not in-tree so we won't put
>> it in PMS. It's not in PMS, so it's not allowed in-tree.
>
> That's only a circular argument if you snip out the rest of the
> sentence.
>
Nonsense. You gave the fact that it's not used in the tree as a reason not
to put it in PMS, did you not? I merely addressed it separately, since it
is a distinct semantic component.

>> I'd like to ask the Council to consider whether EAPI development has
>> not in fact supplanted a large part of the GLEP process (specifically
>> the technical aspects to do with ebuild development.) As such,
>> insisting on all discussion on bugzilla is in fact a subversion of
>> the original process that people have agreed upon.
>
> Moving the discussion to bugzilla was the Council's decision, not mine.
>
Yes, well, I didn't ask you. I asked the Council to consider the broader
picture, which is their role, since effectively GLEPs are now only for
non-technical things, or might as well be, since all future ebuild
directions are EAPI by definition. Having wider input (which is what this
list is for) might avoid future blind-alleys.

Nevertheless, I'm sure they'll take your valuable insight under
consideration, as well as the history and any lobbying that might have gone
on at the time, assuming they were around and haven't suppressed the
memory.

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Le 18/08/2009 03:30, Steven J Long a écrit :
[snip]

Steven,

This thread was dead for more than 4 days. Yet you pick it up and you
try to pick a fight with Ciaran.

I for one am tired of your behavior on this list and I will not hesitate
to contact UserRel to get you out of this list if you don't settle down
and start acting like an adult.

Now step away from this thread.

Thanks

Rémi

Steven J Long wrote:
> Rémi Cardona wrote:
>
>
>> Le 18/08/2009 03:30, Steven J Long a écrit :
>> [snip]
>>
>> Steven,
>>
>> This thread was dead for more than 4 days. Yet you pick it up and you
>> try to pick a fight with Ciaran.
>>
>>
> No I was answering the points he made, specifically he gave the fact that
> something's not used in the tree as a reason not to put it in PMS. The
> prior mail about an alternative perspective on the process was about his
> continual digs at portage and its developers. You're right that much of it
> was more relevant to -project, but when I post there it gets ignored:
> http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml
> http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml
>

I think it's clear at this point that Ciaran was the wrong person to
have in charge of the PMS or EAPI spec's despite his willingness to do
the work.. I tried to talk to him about having Paludis support an
extension of PMS which Portage already supported. His response was to
DEMAND that portage change his behavior and throw warnings about this
because it wasn't in the PMS (which I will note is an accurately
acronym'd document).

ttp://bugs.gentoo.org/show_bug.cgi?id=273261

The users simply don't care about this stuff, and throwing warnings at
every user in the manner advocated is abuse.

This sort of behavior simply needs to stop. Using bugs.gentoo.org to
attack Funtoo, which utilizes Portage, in the manner which has been done
usurps the Gentoo Council's authority, the Portage devs, Funtoo, and
most importantly our ability to innovate.
And hell, if we're not going to innovate, lets all please pack up and go
home.

Andrew D Kirch
Funtoo





Andrew D Kirch
Funtoo.org

Rémi Cardona wrote:

> Le 18/08/2009 03:30, Steven J Long a écrit :
> [snip]
>
> Steven,
>
> This thread was dead for more than 4 days. Yet you pick it up and you
> try to pick a fight with Ciaran.
>
No I was answering the points he made, specifically he gave the fact that
something's not used in the tree as a reason not to put it in PMS. The
prior mail about an alternative perspective on the process was about his
continual digs at portage and its developers. You're right that much of it
was more relevant to -project, but when I post there it gets ignored:
http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml
http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml

> I for one am tired of your behavior on this list
Fair enough. I'm tired of ciaran's, and I'm bemused that you didn't take the
opportunity to contact me off-list to discuss this. I'm on IRC most of the
time, as any of several Gentoo developers could have told you.

> and I will not hesitate
> to contact UserRel to get you out of this list if you don't settle down
> and start acting like an adult.
>
If you wish to raise a bug go ahead. As for being adult-like, you don't seem
to have behaved so yourself, afaIc. No, some of us don't respond the very
next minute, nor do we consider 4 days a long time. Perhaps for a student
with far too much time on his hands, it might be.

The main point I was talking about was the subversion of the GLEP process by
the EAPI one. You might have missed it; next time try reading the whole
mail.

> Now step away from this thread.
>
Done.
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

On Thu, 20 Aug 2009 06:13:59 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> I think it's clear at this point that Ciaran was the wrong person to
> have in charge of the PMS or EAPI spec's despite his willingness to do
> the work.. I tried to talk to him about having Paludis support an
> extension of PMS which Portage already supported. His response was to
> DEMAND that portage change his behavior and throw warnings about this
> because it wasn't in the PMS (which I will note is an accurately
> acronym'd document).
>
> ttp://bugs.gentoo.org/show_bug.cgi?id=273261

...and then for the feature to be introduced properly, in a controlled
manner, yes.

> The users simply don't care about this stuff, and throwing warnings at
> every user in the manner advocated is abuse.

The warnings don't make it to the user. The warnings make sure
developers catch the problem and fix it.

> This sort of behavior simply needs to stop. Using bugs.gentoo.org to
> attack Funtoo, which utilizes Portage, in the manner which has been
> done usurps the Gentoo Council's authority, the Portage devs, Funtoo,
> and most importantly our ability to innovate.

Funtoo can do whatever it wants. There are plenty of ways for it to do
that. One way might be for Funtoo to make its own EAPI including the
extensions it needs, and get Portage to support that. Unfortunately,
your incorrect belief that EAPIs had nothing to do with Portage when
this came up prevented you from considering that solution.

> And hell, if we're not going to innovate, lets all please pack up and
> go home.

I look forward to seeing Funtoo's creation of EAPI funtoo-2.

--
Ciaran McCreesh