[gentoo-dev] Changing PMS to Portage Manager Specification

[gentoo-dev] Changing PMS to Portage Manager Specification

[William L. Thomson Jr.]

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

I think Gentoo council, developers, and portage developers should
consider changing the PMS, to something like Portage Manager
Specification, or Gentoo Portage Specification. Make it Gentoo
and portage specific, and others adhere to that standard.

I understand the rationale behind PMS. However there is really only 1
main package manager for Gentoo, portage. I am aware of pkgcore,
though thought more of it was in C. I think pkgcore is still behind
EAPI wise, so not at 6 yet. There is paludis, but it requires pretty
heavy changes and does not seem to run along side of portage as it once
did long ago. Not sure if anyone even has a system that has no portage
installed. No emerge command etc.

It seems a few times I have heard portage developers make comments
about being limited by PMS.  That seems odd. To me the PMS should be
limited by portage, not the other way around. PMS should be based on
portage. Then other package managers must change to comply with that
specification. Rather than how things are now.

I have no control or participate in either portage or PMS development.
It is just an observation from having some needs. Which seems could
happen with portage. But can only happen if in the PMS. Which itself is
a process. Not sure in that case the PMS helps to expedite Gentoo
development, and may hinder. Since portage can only do what PMS allows
it to do. I think that should be reversed.

This is not saying drop PMS, have no PMS, etc. Just reverse, free
portage developers to do what they feel is needed for Gentoo. Then
other package managers can adhere to that specification. Make it
entirely internal and specific to Gentoo.

The PMS seems pretty abstract and not specific to Gentoo. Why even
bother with that? Why not Gentoo set its own standards for package
management? It seems aspects of portage are used for things like
Chrome OS and CoreOS, as well as parts of Gentoo. But seems more usage
of portage and not other package managers. Why not make it the
flagship? Portage be the standard, the specification/reference
implementation and others comply.

IMHO PMS should not hold back portage development, but portage
development hold back the PMS. PMS based on portage, not vice versa.

This will be my only post. Feel free to insult me, etc as you like.
Just an idea for others to discuss.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Sam Jorna]

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

On Tue, Aug 01, 2017 at 06:05:00PM -0400, William L. Thomson Jr. wrote:
> I think Gentoo council, developers, and portage developers should
> consider changing the PMS, to something like Portage Manager
> Specification, or Gentoo Portage Specification. Make it Gentoo
> and portage specific, and others adhere to that standard.

If you have a look at the Package Manager Specification project page[1]
it notes that this is how it worked previously and was decided against.

Personally, given that Gentoo is a meta-distribution, it makes more
sense to me to have an independent specification for things like this
and have the "default" package manager essentially be the reference
implementation of the specification. If there's a better way to do
something than what is defined in PMS, then perhaps suggest an update to
it.

[1] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Alexander Berntsen]

[-- Attachment #1.1: Type: text/plain, Size: 272 bytes --]

While the PMS perhaps hasn't been an unequivocal success, it's still a
good effort with some success. I would be disappointed to see the
proposed change, and view it as a bad sign for Gentoo.
-- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander


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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Gordon Pettey]

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

On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen <bernalex@gentoo.org>
wrote:

> While the PMS perhaps hasn't been an unequivocal success, it's still a
> good effort with some success. I would be disappointed to see the
> proposed change, and view it as a bad sign for Gentoo.
>

Also, how many Portages are there that need to be managed with a "Portage
Manager"?

[-- Attachment #2: Type: text/html, Size: 756 bytes --]

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Peter Stuge]

Alexander Berntsen wrote:
> While the PMS perhaps hasn't been an unequivocal success, it's still a
> good effort with some success. I would be disappointed to see the
> proposed change, and view it as a bad sign for Gentoo.

As far as technical documentation about how ebuilds work (the core of
Gentoo, but also many other distributions; I have created several of
my own), PMS is an absolutely amazing document!

It comes down to whether Gentoo is a "meta-distribution" with
absolutely amazing generic tooling (including portage), or "simply" a
source-based distribution with an arbitrary package format.

PMS has tremendous value, and yes, EAPI is a process, and I am sure
that portage developers gnash their teeth at blockers stemming from
PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
all better off for it.

Without knowing specifics I guess I would suggest to the original
poster to create new tooling for the job that needs to be done. Maybe
even a fork of portage, at first only used in your (derivative)
Gentoo distribution? Just my idea for a possible solution.


//Peter

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Rich Freeman]

On Mon, Aug 14, 2017 at 2:42 PM, Peter Stuge <peter@stuge.se> wrote:
>
> I am sure
> that portage developers gnash their teeth at blockers stemming from
> PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
> all better off for it.
>

Honestly, I've yet to see any portage developers complaining about PMS here.

In general the main hoops to jump through if you want something in PMS are:

1.  A well-thought-out design.  (May involve list bikeshedding/etc,
with input from the portage team and other interested parties being
key.)
2.  A portage implementation.  (Which is an issue if you want
something in portage no matter what.)
3.  Council approval.  (Which tends to happen if you have #1-2 and
aren't just ignoring list feedback.)

It is pretty common for people to do them in the order 1-3-2 with 3
being a provisional approval so that the portage developers don't spin
their wheels.

Usually when #1 ends up being the hangup there tend to be serious
concerns about how the concept will work in reality.  If it will make
ebuilds harder to maintain or their behavior less predictable then an
implementation alone isn't enough.  Either that or there are concerns
that the design doesn't fully address the need, which often happens
when we add a new dependency type.

IMO the process isn't really broken, and I doubt that changing the
name would change anything.  We don't wait for other package managers
to support a new PMS version before using it in the tree.  We do value
the input of anybody with expertise in this area, though the Council
holds the final say.  PMS has a huge impact on our QA and I think
we're generally better off for the time spent on it.

If somebody actually does have a PMS proposal that has been stalled it
wouldn't hurt to share it, or if the portage team feels otherwise.

-- 
Rich

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[William L. Thomson Jr.]

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

On Mon, 14 Aug 2017 18:42:21 +0000
Peter Stuge <peter@stuge.se> wrote:

> Alexander Berntsen wrote:
> > While the PMS perhaps hasn't been an unequivocal success, it's
> > still a good effort with some success. I would be disappointed to
> > see the proposed change, and view it as a bad sign for Gentoo.  
> 
> As far as technical documentation about how ebuilds work (the core of
> Gentoo, but also many other distributions; I have created several of
> my own), PMS is an absolutely amazing document!

I was not suggesting to get rid of it. Said another way,
What is the reference implementation of PMS?

Java has lots of specs, and usually a reference implementation. In the
case where there is no implementation is where companies compete. Thus
would not be in any benefit to assist the other with an implementation.

> It comes down to whether Gentoo is a "meta-distribution" with
> absolutely amazing generic tooling (including portage), or "simply" a
> source-based distribution with an arbitrary package format.

I am suggesting Gentoo be the reference implementation, portage be the
reference implementation of PMS. It should be limited by the developers
not outsiders.

I cannot explain why those who do portage development are not the PMS
authors. As a developer, it seems something is off there.

> PMS has tremendous value, and yes, EAPI is a process, and I am sure
> that portage developers gnash their teeth at blockers stemming from
> PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
> all better off for it.

EAPI is surely a process, I came across a EAPI=2 ebuild the other day,
and still likely some EAPI=0 in tree. I would not consider EAPI to be a
success by any means.

It creates waves of "wheel spinning". Revising the internals of an
ebuild for little to no gain. If I updated that EAPI=2 ebuild. The
installed result would be no different. Given that fact, I see no
benefit to EAPI=6 over EAPI=2.

> Without knowing specifics I guess I would suggest to the original
> poster to create new tooling for the job that needs to be done. Maybe
> even a fork of portage, at first only used in your (derivative)
> Gentoo distribution? Just my idea for a possible solution.

I am not using a derived distributions. I am running Gentoo with a
massive overlay due to the amount of packages not updated in tree.

My overlay would not exist if I could have returned. I cannot improve
from within thus I am limited to an overlay on top. But I am not
running some other distro or making my own.

I have warm and open offers to be part of Funtoo. None of my systems
run that. All my systems, servers and workstations run Gentoo. Just
with a massive overlay slapped on top.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Rich Freeman]

On Mon, Aug 14, 2017 at 4:42 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
>
> I cannot explain why those who do portage development are not the PMS
> authors.
>

Have you considered asking them?

-- 
Rich

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[William L. Thomson Jr.]

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

On Mon, 14 Aug 2017 15:09:15 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Aug 14, 2017 at 2:42 PM, Peter Stuge <peter@stuge.se> wrote:
> >
> > I am sure
> > that portage developers gnash their teeth at blockers stemming from
> > PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
> > all better off for it.
> >  
> 
> Honestly, I've yet to see any portage developers complaining about
> PMS here.

There are not that many, the core ones tend to do most the work
https://github.com/gentoo/portage/graphs/contributors

But I do not seem them participating here much.
https://gitweb.gentoo.org/proj/pms.git/

Also not sure that is mirrored to Github for what ever reason. To major
flags, no mirror to github, and little to no involvement from core
portage developers. That seems like a disconnect there.

Why would it not be mirred to Github? Not wanting outside PRs or input
on PMS?

> In general the main hoops to jump through if you want something in
> PMS are:

From a developer perspective, jumping through hoops will limit
creativity, and if nothing else hold back development. I tend to prefer
to keep development more unrestrained.

> Usually when #1 ends up being the hangup there tend to be serious
> concerns about how the concept will work in reality.  If it will make
> ebuilds harder to maintain or their behavior less predictable then an
> implementation alone isn't enough.  Either that or there are concerns
> that the design doesn't fully address the need, which often happens
> when we add a new dependency type.

Portage supports sets, but the PMS has no mention. Then there is debate
on what they are. Creating so much noise it drowns the bug request and
makes it invalid. Despite the need still existing, and PMS lacking
anything on  sets. 
https://bugs.gentoo.org/show_bug.cgi?id=624300
 
> IMO the process isn't really broken, and I doubt that changing the
> name would change anything.  We don't wait for other package managers
> to support a new PMS version before using it in the tree. 

More like package managers cannot add features not mentioned by PMS.

> We do value
> the input of anybody with expertise in this area, though the Council
> holds the final say.  PMS has a huge impact on our QA and I think
> we're generally better off for the time spent on it.

PMS I do not see as related to QA. It is something for other package
managers. I fail to see how PMS makes QA better. If anything repoman
makes QA better. I would have to double check but I bet many things
repoman looks out for is not in PMS.

> If somebody actually does have a PMS proposal that has been stalled it
> wouldn't hurt to share it, or if the portage team feels otherwise. 

Just the needs I have with portage are stalled, marked as invalid. No
discussion for inclusion in PMS. Like documenting sets.


-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[William L. Thomson Jr.]

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

On Sat, 12 Aug 2017 09:55:02 -0500
Gordon Pettey <petteyg359@gmail.com> wrote:

> On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen
> <bernalex@gentoo.org> wrote:
> 
> > While the PMS perhaps hasn't been an unequivocal success, it's
> > still a good effort with some success. I would be disappointed to
> > see the proposed change, and view it as a bad sign for Gentoo.
> >
> 
> Also, how many Portages are there that need to be managed with a
> "Portage Manager"?

If your asking about alternative package managers, I am aware of 2

paludis - requires heavy modification to environment
pkgcore - does not support EAPI 6, only experimental EAPI 5

pkgcore existed before PMS, and seems like more development before PMS
https://github.com/pkgcore/pkgcore/graphs/contributors

IMHO PMS was mostly about paludis and not Gentoo or portage. I recall
how it came about and the people behind the effort.
~2007-02-09
http://marc.info/?l=gentoo-dev&w=2&r=86&s=pms&q=b


https://wiki.gentoo.org/wiki/Paludis
https://wiki.gentoo.org/wiki/Pkgcore

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Rich Freeman]

On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
>
> Portage supports sets, but the PMS has no mention. Then there is debate
> on what they are. Creating so much noise it drowns the bug request and
> makes it invalid. Despite the need still existing, and PMS lacking
> anything on  sets.
> https://bugs.gentoo.org/show_bug.cgi?id=624300
>
> Just the needs I have with portage are stalled, marked as invalid. No
> discussion for inclusion in PMS. Like documenting sets.

Ah, well, that's the main mystery of this thread solved.  Thanks.

-- 
Rich

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Gordon Pettey]

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

On Mon, Aug 14, 2017 at 4:46 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

> On Sat, 12 Aug 2017 09:55:02 -0500
> Gordon Pettey <petteyg359@gmail.com> wrote:
>
> > On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen
> > <bernalex@gentoo.org> wrote:
> >
> > > While the PMS perhaps hasn't been an unequivocal success, it's
> > > still a good effort with some success. I would be disappointed to
> > > see the proposed change, and view it as a bad sign for Gentoo.
> > >
> >
> > Also, how many Portages are there that need to be managed with a
> > "Portage Manager"?
>
> If your asking about alternative package managers, I am aware of 2
>

I'm not. I'm pointing out that just changing the meaning of P in PMS to
Portage makes the acronym nonsense unless you remove or change the M too.

[-- Attachment #2: Type: text/html, Size: 1336 bytes --]

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[William L. Thomson Jr.]

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

On Mon, 14 Aug 2017 15:20:26 -0700
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> >
> > Portage supports sets, but the PMS has no mention. Then there is
> > debate on what they are. Creating so much noise it drowns the bug
> > request and makes it invalid. Despite the need still existing, and
> > PMS lacking anything on  sets.
> > https://bugs.gentoo.org/show_bug.cgi?id=624300
> >
> > Just the needs I have with portage are stalled, marked as invalid.
> > No discussion for inclusion in PMS. Like documenting sets.  
> 
> Ah, well, that's the main mystery of this thread solved.  Thanks.

That is the tip of the iceberg, not the main problem itself. I have
never been a fan of EAPI, or the resulting PMS, etc. Having been around
before such existed, I do not believe it has helped Gentoo and in fact
maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.

Now becoming more real issues rather than just a dislike of EAPI.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Michał Górny]

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

On pon, 2017-08-14 at 18:39 -0400, William L. Thomson Jr. wrote:
> On Mon, 14 Aug 2017 15:20:26 -0700
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> > On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
> > <wlt-ml@o-sinc.com> wrote:
> > > 
> > > Portage supports sets, but the PMS has no mention. Then there is
> > > debate on what they are. Creating so much noise it drowns the bug
> > > request and makes it invalid. Despite the need still existing, and
> > > PMS lacking anything on  sets.
> > > https://bugs.gentoo.org/show_bug.cgi?id=624300
> > > 
> > > Just the needs I have with portage are stalled, marked as invalid.
> > > No discussion for inclusion in PMS. Like documenting sets.  
> > 
> > Ah, well, that's the main mystery of this thread solved.  Thanks.
> 
> That is the tip of the iceberg, not the main problem itself. I have
> never been a fan of EAPI, or the resulting PMS, etc. Having been around
> before such existed, I do not believe it has helped Gentoo and in fact
> maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.
> 
> Now becoming more real issues rather than just a dislike of EAPI.
> 

Yes, it would be much better if we didn't have EAPI and instead of old
EAPI=0 ebuilds we would just have old ebuilds that install half-broken
packages because of ebuild incompatibility.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 433 bytes --]

On 2017-08-14 23:46, William L. Thomson Jr. wrote:

> pkgcore - does not support EAPI 6, only experimental EAPI 5

Side note - according to

https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

pkgcore has supported EAPI 6 since version 0.9.3. Considering it says
exactly the same for EAPI 5, this is almost certainly a mistake - but
I'd rather confirm this here before changing the page.

-- 
Marecki


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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Ulrich Mueller]

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

>>>>> On Wed, 16 Aug 2017, Marek Szuba wrote:

> On 2017-08-14 23:46, William L. Thomson Jr. wrote:
>> pkgcore - does not support EAPI 6, only experimental EAPI 5

> Side note - according to

> https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

> pkgcore has supported EAPI 6 since version 0.9.3.

Right, the information on the wiki page is taken from pkgcore's NEWS
file.

> Considering it says exactly the same for EAPI 5, this is almost
> certainly a mistake - but I'd rather confirm this here before
> changing the page.

Unfortunately, information about EAPI 4 and 5 support is not entirely
clear from the NEWS file, so one must look into the git log. Quoting
bug 326459 comment 4 [1]:

   EAPI 4: pkgcore-0.6.5 (2011-06-22), which is the first version
   (correctly) supporting default src_install. There's another change
   for EAPI 4 in 0.7, namely removal of the AA and KV variables, but I
   think this can be ignored here (also it's not in the NEWS file).

   EAPI 5: pkgcore-0.9.3 (2016-05-28). NEWS says for 0.9 that it has
   "Nearly complete EAPI=5 support just missing subslot rebuilds."
   This was finally added in 0.9.3, "Add support for PN:slot/subslot
   and slotted glob targets."

So yes, it appears that full support for EAPI 5 was added only in
pkgcore-0.9.3, which supports EAPI 6 already.

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=326459#c4

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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Tim Harder]

On 2017-08-16 05:56, Ulrich Mueller wrote:
> > Considering it says exactly the same for EAPI 5, this is almost
> > certainly a mistake - but I'd rather confirm this here before
> > changing the page.

> Unfortunately, information about EAPI 4 and 5 support is not entirely
> clear from the NEWS file, so one must look into the git log. Quoting
> bug 326459 comment 4 [1]:

>    EAPI 4: pkgcore-0.6.5 (2011-06-22), which is the first version
>    (correctly) supporting default src_install. There's another change
>    for EAPI 4 in 0.7, namely removal of the AA and KV variables, but I
>    think this can be ignored here (also it's not in the NEWS file).

>    EAPI 5: pkgcore-0.9.3 (2016-05-28). NEWS says for 0.9 that it has
>    "Nearly complete EAPI=5 support just missing subslot rebuilds."
>    This was finally added in 0.9.3, "Add support for PN:slot/subslot
>    and slotted glob targets."

> So yes, it appears that full support for EAPI 5 was added only in
> pkgcore-0.9.3, which supports EAPI 6 already.

Just to note, I consider pkgcore-0.9 to support EAPI 5 nearly as far as
PMS specifies. The news item you pointed out has more to do with adding
subslot input support for cli tools (pmerge, pquery, etc) which doesn't
have anything to do with PMS.

Tim

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2900 bytes --]

On 08/14/2017 03:39 PM, William L. Thomson Jr. wrote:
> On Mon, 14 Aug 2017 15:20:26 -0700
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
>> <wlt-ml@o-sinc.com> wrote:
>>>
>>> Portage supports sets, but the PMS has no mention. Then there is
>>> debate on what they are. Creating so much noise it drowns the bug
>>> request and makes it invalid. Despite the need still existing, and
>>> PMS lacking anything on  sets.
>>> https://bugs.gentoo.org/show_bug.cgi?id=624300
>>>
>>> Just the needs I have with portage are stalled, marked as invalid.
>>> No discussion for inclusion in PMS. Like documenting sets.  
>>
>> Ah, well, that's the main mystery of this thread solved.  Thanks.
> 
> That is the tip of the iceberg, not the main problem itself. I have
> never been a fan of EAPI, or the resulting PMS, etc. Having been around
> before such existed, I do not believe it has helped Gentoo and in fact
> maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.
> 
> Now becoming more real issues rather than just a dislike of EAPI.
> 
I'm unaware of any other way to introduce progressive changes to an API
without literally rewriting every ebuild. Versioned APIs are good APIs,
and give developers (both inside and outside Gentoo) something they can
depend on and, most importantly, predict. If there was just one EAPI,
you'd need to consult git log or some other construct to figure out the
API version an ebuild was written against.

The fact we still have older EAPI ebuilds is one of manpower and
(dis)interest. I don't see anyone trying to prevent (or encourage) EAPI
upgrading across the tree. Generally, we wait until a package needs a
revbump/version bump and/or has serious breakage (and thus needing a
rewrite) before bumping EAPI. Some jumps in EAPI, for simple packages,
are painless. Others are a nightmare.

I see no other way to support the 1m+ ebuilds that have been written
since Gentoo's inception in an unambiguous, reference-able way. In fact,
I'd argue if you don't version your APIs, you're not designing them
correctly. APIs *will* change; building a version number into the API
ensures the consumers of said API are aware of changes.

That said, yes, it'd be nice if every ebuild was EAPI 6, but that is a
huuuuge amount of work that nobody seems interested in, for questionable
gain. The work would just be repeated when the next EAPI is approved.
The way it works now is more organic and better representative of the
state of Gentoo development, for better or worse.

It's good to see you taking part in constructive discussions! That's not
intended as sarcasm. I mean it. Thanks for taking part.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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