[gentoo-project] Re: Enough about GLEP5{4,5}

[Steven J Long]

Roy Bamford wrote:

> Rémi Cardona wrote:
>> Seriously, let's stop.
>>
>> This endless debate has gone on for waaay too long and it is just
>> plain
>> spam now.
>
> [snip]
>
>> Let's just all agree we've failed to reach a consensus and let's
>> spend time on something else.
>
I agree it's tiresome. 
>
> I think that GLEP55 has failed so far because it has always been
> inadequately documented in the GLEP.
>
If the problem had been adequately communicated in the first place
(which is pretty much required for any proposal ime) instead of people
being told they "don't understand so go away" we could have agreed
then, that the issue was simply about knowing the EAPI before sourcing.

As it is, we _finally_ have grudging submission that tightening the PMS
to reflect QA reality works but is not "the best solution."

> The problem won't be addressed by spending time on something else.
> The one big problem needs to be broken down recursively into smaller
> problems that can be addressed individually, rather like a very old
> asteriods game.
>
Let's do that with a statement made in objection to just doing what
we're doing:
< ciaranm> NeddySeagoon: objectively, you have to either not change
version format rules ever, or force the package manager to open() every
ebuild rather than no ebuilds before it can find the best version of
something

(Even though the case for changing version format has not been made, the
argument applies to the other incompatible changes affecting global
environment.)

Firstly, and most significantly, this only applies when the mangler does
not have the ebuild metadata in cache. Bear in mind portage automatically
caches overlays under /var/cache/edb, and that we distribute a metadata
cache via rsync for the main tree, so interactive performance does not
suffer in any event.

Cache design is open to improvement. Once we've broken encapsulation, we
cannot take it back. And it WILL lead to maintenance headaches.

Secondly, for the mangler to determine the "best-visible", EAPI is not the
only item under consideration. So again, there is a lie implicit: whether
from cache or from file, the mangler will ALWAYS need some metadata on the
ebuilds; CPV + EAPI is insufficient.

At very best, all EAPI in filename (wherever it is) does, is limit the set
of ebuilds to those with a supported EAPI before the cache has to be
consulted. For Gentoo users (who update as recommended) using Gentoo
product, that's _every_ ebuild in the tree and overlays.

So what practically are we accomplishing for our users?

And how much developer time would be wasted to do so, and indeed has already
been wasted on this? Time that could be spent improving the cache, binhost
support, completing the ebuild spec, writing ebuilds, or just having a
life. ;)

[There's no reason a repo providing an overlay couldn't use an eapi file
the same as profiles (sorry I don't know if this is already done) for
experimental herd stuff.]

> If we get a solution, Gentoo can be first into the future again, if
> not, we will always be last out of the past.
>
> Gentoo needs a way to introduce new features without waiting over a
> year to provide backwards compatibility.
>
We already have it.

We just can't allow a new, incompatible EAPI until we have an upgrade
path agreed for people on older versions of portage than 2.2 whenever
that EAPI comes out.

Or we just agree that we're not bothered if they get not-so-friendly
error messages for ebuilds from overlays which happen to use the new
EAPI. After all, most people will be using the cache; it's important
to remember that, and that in that case, no sourcing will happen in
any event, and nor will any of those error messages. If they need an
ebuild using an unsupported EAPI, they'll get the "unsupported EAPI"
message.

If not, they get a grotty error message; so what? It's not going to break
anything and presumably they'd be on a deprecated profile in any case, so
would already have been shouted at in no uncertain terms about upgrading,
along with a url to consult.

The real problem that is glaringly obvious to any external is the process
that allows Gentoo to be deflected from its strategic interests for over a
year on a technically-lamentable proposal. I for one would like to know how
prospective Council members intend to address that.

(If you don't think it is a problem, please feel free to say so /without/
resorting to insult over reason. If you think the proposal had merit: how
come we've only now got agreement that easily-extractable EAPI works?)

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