[gentoo-dev] RFC: Make 10.0 profiles EAPI-2 'compliant'

Jeremy Olexa · External Since: Aug 12, 2009 Posts: 5

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

Ben de Groot · External Since: Aug 12, 2009 Posts: 4

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

Samuli Suominen · External Since: Jun 02, 2009 Posts: 22

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

Mark Bateman · External Since: Aug 13, 2009 Posts: 3

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

Nirbheek Chauhan · External Since: May 26, 2009 Posts: 6

On Thu, Aug 13, 2009 at 4:05 PM, Tiziano MÃ¼ller<dev-zero.DeleteThis@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

Mark Bateman · External Since: Aug 13, 2009 Posts: 3

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

Mark Bateman · External Since: Aug 13, 2009 Posts: 3

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

Steven J Long · External Since: Aug 13, 2009 Posts: 5

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe.TakeThisOut@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 Wink

Steven J Long · External Since: Aug 13, 2009 Posts: 5

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 19:22:16 +0100
> Steven J Long <slong.TakeThisOut@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 Wink

Rémi_Cardona · External Since: Dec 10, 2004 Posts: 20

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 · External Since: Aug 13, 2009 Posts: 5

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_6c82019575749b628de20de0...49782.x
http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b0...21d53.x

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

Andrew D Kirch · External Since: Aug 20, 2009 Posts: 4

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_6c82019575749b628de20de0...49782.x
> http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b0...21d53.x
>

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

Andrew D Kirch · External Since: Aug 20, 2009 Posts: 4

Ciaran McCreesh wrote:
> On Thu, 20 Aug 2009 06:13:59 -0400
> Andrew D Kirch <trelane.DeleteThis@trelane.net> wrote:
>
>
> > I look forward to seeing Funtoo's creation of EAPI funtoo-2.
>

Obviously you don't get it. We aren't going to spend time writing this
sort of spurious and unnecessary specification documents. The fact that
this is even conscionable would be hugely concerning except for the fact
that you are not a Gentoo dev. Nor do you, as I have proven, have
standing to file such a bug as you are not on the council (even as an
alternate), and the SOLE option for packages violating PMS per the
council is a council vote to mask the package.

I'm having a hard time reconciling the following:

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

And:

"Just do it unconditionally. We're talking the tree here, not user
configuration files, so enforcing QA can only be a good thing."
"Portage should instead warn or error when this happens to prevent
people from accidentally abusing this."

Also:

"No. It's in direct violation of PMS, and only accidentally works with
Portage until Portage is fixed."

And:

"Portage should instead warn or error when this happens to prevent
people from accidentally abusing this."

Portage is a tool used by users, repoman is a tool used by developers
for tree QA. Considering the zeal with which you are pushing this
"accidentally works with Portage until Portage is fixed", I believe a
reasonable person is going to look at the b.g.o bug, and at the Paludis
bug and realize that you're more interested in process than innovation,
and that you simply don't care about throwing needless confusing
warnings at users (indeed a prima facia examination of Paludis would
seem to confirm this, and my concerns WRT Paludis and the development
methods are well known). I think they'll also realize that throughout
this process you've been less than honest, and a huge impairment to the
work going on at Funtoo.

Would someone who has access please resolve the bug as WONTFIX? Thanks.

Andrew D Kirch
Funtoo.org

Steven J Long · External Since: Aug 13, 2009 Posts: 5

Ciaran McCreesh wrote:

> I look forward to seeing Funtoo's creation of EAPI funtoo-2.
>
Well judging by your EAPI-2, I'd prefer it. Apart from USE-deps, there's
been no discussion apart from under your supervision on bugzie.
nonfatal? (or w/e it's called.) Who came up with that idea, and why did you
ignore the --or-die option that's already been discussed?

If you want exceptions, try C++ (better than you're currently doing.) This
is shellscript.

I'd like to moot to the Council that we hold off on EAPI-2 profiles, and go
with EAPI-1 plus USE-deps and BASH-3.2_p17 (honestly, you thought 4 was
ready?!) til we get this mess sorted.

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

Chip Parker · External Since: Aug 10, 2009 Posts: 7

On Thu, Aug 20, 2009 at 5:04 PM, Steven J
Long<slong.TakeThisOut@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
>
>> I look forward to seeing Funtoo's creation of EAPI funtoo-2.
>>
> Well judging by your EAPI-2, I'd prefer it. Apart from USE-deps, there's
> been no discussion apart from under your supervision on bugzie.
> nonfatal? (or w/e it's called.) Who came up with that idea, and why did you
> ignore the --or-die option that's already been discussed?
>
> If you want exceptions, try C++ (better than you're currently doing.) This
> is shellscript.
>
> I'd like to moot to the Council that we hold off on EAPI-2 profiles, and go
> with EAPI-1 plus USE-deps and BASH-3.2_p17 (honestly, you thought 4 was
> ready?!) til we get this mess sorted.
>

How about we just ignore ciaranm because he's got no valid complaints
or objections to this particular portage behavior as shown in
https://bugs.gentoo.org/show_bug.cgi?id=273261#c28.

Relevant portion excerpted here for your convenience:
"Additionally, in
http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py...v=3495&
(hint: look for "recursive=1") and
http://bugs.gentoo.org/show_bug.cgi?id=133740, with both predating the
initial RFC for PMS sent to gentoo-dev mailing list, this behavior is
discussed and shown to be a design feature, not a flaw or lack of QA
in portage. This proves with certainty that it is PMS and the views of
the reporter of this bug that are flawed, and not the behavior of
portage."

Problem solved.

David Leverton · External Since: Apr 01, 2009 Posts: 6

2009/8/21 Arfrever Frehtes Taifersar Arahesis <Arfrever DeleteThis @gentoo.org>:
> Portage documentation has been properly fixed (and the fix will be released
> in next version) and this feature can now be used in 10.0 profiles.

No. Changing the documentation does not retroactively change existing EAPIs.

Chip Parker · External Since: Aug 10, 2009 Posts: 7

2009/8/21 Robert Buchholz <rbu DeleteThis @gentoo.org>:
> On Saturday 22 August 2009, Maciej Mrozowski wrote:
>> It's true, but being able to modularize profile may outweights the
>> need to be strict-with-the-book here - it's a matter of usefulness. I
>> think it should be decided by those who actually do the work in
>> profile, whether it's worthy to push this now instead of waiting for
>> EAPI approval.
>>
>> So, can profile developers share their view?
>
> We have kept SLOT dependencies and other >EAPI-0 features out of the
> tree profiles, introduced profile EAPI versioning to foster
> interoperability. Now what you propose is to break this deliberate
> upgrade process to introduce a feature no one proposed for the profiles
> directory in the last years?
>
> I wonder what the value of the PMS specification is if every time an
> inconsistency comes up the argument is raised that it should document
> portage behavior. EAPI 1, 2 and 3 have been agreed by the council and
> PMS is in a stage where Portage should obey its definitions and not the
> other way around.
> I am not saying that this is the *fastest* way to innovate (although in
> my opinion it is a good way to keep interoperability).
> However this PMS process is what council has chosen for Gentoo, and
> either you follow it, or you try to improve it (working with the PMS
> subproject people), or you bring up a proposal to redefine how we
> handle standards within the tree.
>
> Trying to ignore the fact this standard exists is a way to breakage.
>
>
> Robert
>

When the PMS "subproject" is overwhelmingly ruled by a single person
who doesn't have official Gentoo developer status and yet it is
allowed to remove features from portage (the reference implementation)
that predated PMS at the direction of this same non-dev, you start to
have a very big problem.

If you were building a house, and the blueprints had been signed off
on calling for 1 meter high doors, but the builder had built in 2
meter high doors, would you then go back to the builder and require
him to do something that makes those doors unusable for the vast
majority of people entering the house?

If this feature, which HAD been documented (in bugzilla and
commitlogs) prior to the first RFC for PMS, had instead been added
yesterday, I would completely agree that we should revert it and it
should be part of a future specification. Since this is instead a
situation where the blueprints were wrong and the builder was correct,
let's not go throwing away our "normal sized" doors.

Since I, as well as the only person who's loudly having an issue with
portage and PMS not matching up in this respect, are both USERS and
NOT Gentoo developers, it's my opinion that portage should be left
alone and PMS should be corrected to align with the spirit, if not the
letter of what was documented WELL after the initial commit that added
the feature. And, since I and the main contributor to PMS are both
users, it's also my opinion that NEITHER of us should have anything to
do with the policy/specification defining package manager behavior for
the most prolific package manager in use today.

AllenJB · External Since: May 26, 2009 Posts: 4

Robert Buchholz wrote:
> On Saturday 22 August 2009, Maciej Mrozowski wrote:
>> It's true, but being able to modularize profile may outweights the
>> need to be strict-with-the-book here - it's a matter of usefulness. I
>> think it should be decided by those who actually do the work in
>> profile, whether it's worthy to push this now instead of waiting for
>> EAPI approval.
>>
>> So, can profile developers share their view?
>
> We have kept SLOT dependencies and other >EAPI-0 features out of the
> tree profiles, introduced profile EAPI versioning to foster
> interoperability. Now what you propose is to break this deliberate
> upgrade process to introduce a feature no one proposed for the profiles
> directory in the last years?
>
> I wonder what the value of the PMS specification is if every time an
> inconsistency comes up the argument is raised that it should document
> portage behavior. EAPI 1, 2 and 3 have been agreed by the council and
> PMS is in a stage where Portage should obey its definitions and not the
> other way around.
> I am not saying that this is the *fastest* way to innovate (although in
> my opinion it is a good way to keep interoperability).
> However this PMS process is what council has chosen for Gentoo, and
> either you follow it, or you try to improve it (working with the PMS
> subproject people), or you bring up a proposal to redefine how we
> handle standards within the tree.
>
> Trying to ignore the fact this standard exists is a way to breakage.
>
>
> Robert

From what I've seen here, at least part of the problem here stems from
the fact that this feature won't be considered until EAPI-4, and that
means it might be a long way off yet. This, in my mind, raises the
question of whether the current PMS/EAPI process is too slow in certain
circumstances and could it be modified to speed things up when deemed
necessary?

Could there be room for "fast track" EAPI's to be considered on some
occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the
"package.* as directory in profiles" feature included?

If this is a matter of what the council has decided, would a simple
solution be to have a motion for amendment / fast-track of EAPI2.1 (or
alternative solution) brought up and voted on by the council?

AllenJB

Duncan · External Since: Jun 05, 2004 Posts: 205

Robert Buchholz posted on Sat, 22 Aug 2009 01:44:51 +0200 as excerpted:

> I wonder what the value of the PMS specification is if every time an
> inconsistency comes up the argument is raised that it should document
> portage behavior. EAPI 1, 2 and 3 have been agreed by the council and
> PMS is in a stage where Portage should obey its definitions and not the
> other way around.

> Trying to ignore the fact this standard exists is a way to breakage.

There are, as I see it, two issues here.

1) This feature can be reasonably argued to have fallen thru the cracks,
since it was actually implemented before PMS. Yes, the committing
documentation said it was for user config only, but the implementation
was in general, and in general, EAPI-0 was to document existing behavior,
so we have a problem. It's thus one of a very limited number of
candidates, and it's not like there's going to be hundreds more where
this came from.

2) If I'm not mistaken, EAPI-0 has never been fully finalized anyway. It
has gotten to preliminary approval, where bugs are supposed to be filed
where there's a conflict, and a resolution worked out. All other
approved EAPIs have been defined as differences from previous versions,
but due to the way EAPI-0 came about, nobody has really been sure enough
it's 100% defined, and final approval hasn't happened as a result. Given
that this feature was there before PMS. despite what the documentation
actually said, it's precisely the type of bug that was intended to be
covered by the preliminary approval, and hammering it out as that
preliminary approval outlined is where we're at right now.

If #2 is indeed correct, then we don't have a loophole, we have a
legitimate bug that's we're in the process of hashing out, and it's not
at all clear cut whether the bug is in portage and arguably the original
documentation or in PMS. That's a matter of viewpoint that will likely
take a council vote to solve.

However, as I pointed out on the bug, either way it's not particularly
difficult to solve it. Should council decide to run with the existing
portage behavior, since it has been there for years, the old pre-PMS wait-
a-year before changes can be allowed in tree need not apply. I suggested
30-90 days before it's allowed in official overlays, and 90-180 days
before it's allowed in-tree, altho using it only in the new profiles
works too.

If it goes the other way, then as Zac points out, it's a simple matter to
change the portage documentation once again, and since it's not in-tree
yet (well, at least before the new-profile announcement, and anything
that new and limited to them can be reverted fairly easily too), not a
big deal. It can then wait for EAPI-4

But regardless, it /does/ appear it'll take a council vote on this, one
way or the other. The matter has been requested for the next council
meeting. I'd hope everybody can agree to just slow down a bit until
then. (Zac just committed a portage documentation note mentioning it's
not in PMS yet, and no intervening releases have been made with the
questioned wording /without/ that clause, AFAIK, so that end's covered.)
If at that point it's postponed, that too is effectively a decision, but
I should hope it won't be postponed, as it's relatively simple either
way, and we need a resolution from council, as the authoritative body
designated to resolve such issues, both in general, and if I'm not
mistaken, in the preliminary EAPI-0 approval.

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

Andrew D Kirch · External Since: Aug 20, 2009 Posts: 4

Ryan Hill wrote:
> On Fri, 21 Aug 2009 17:29:12 -0700
> Chip Parker <infowolfe.TakeThisOut@gmail.com> wrote:
>
>
>> If you were building a house, and the blueprints had been signed off
>> on calling for 1 meter high doors, but the builder had built in 2
>> meter high doors, would you then go back to the builder and require
>> him to do something that makes those doors unusable for the vast
>> majority of people entering the house?
>>
>
> Package managers can implement whatever extra bells and whistles they like,
> but they still have to follow the spec. Your metaphor is flawed in that
> you're talking about a single house here. If it doesn't match the plan you
> do an as-built and file a deviation with the registrar. The situation here
> is more like if you build a hundred houses to code, and then one above code,
> and then change code to match the one house and bulldoze the rest for not
> meeting minimal requirements. You're punishing anyone who implements a
> package manager to spec if you keep changing the spec in incompatible ways.
>
Right, this is called "punishing innovation". It's a hobby of
bureaucrats everywhere.
It could also be said to be "punishing excellence". We've had a lot of
political systems
which try to implement a design which weeds out both the mediocre, and
the excellent,
leaving us with the average all have been failures. The reason why
they fail is that it is
the above average who do the heaviest lifting.

Andrew D Kirch
Funtoo.org