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

[Ciaran McCreesh]

On Mon, 08 Jun 2009 19:17:56 +0100
Steven J Long <slong@××××××××××××××××××.uk> wrote:
> 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.

That is not what the issue is. That is half of what the issue is.

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

No, it would not be to reflect reality. We would have to tighten the
rules in such a way that it breaks things people have already done, and
if we were to do so it would either impose performance penalties or not
allow us the full scope of changes, and it would still require us to
wait a year or more before going ahead with any of these changes.

> (Even though the case for changing version format has not been made,

The Council disagrees.

> the argument applies to the other incompatible changes affecting
> global environment.)

No, that's a separate issue, and does not have the same performance
implications.

> Firstly, and most significantly, this only applies when the mangler
> does not have the ebuild metadata in cache.

Not true.

> Bear in mind portage automatically caches overlays
> under /var/cache/edb

You are confusing the dep cache with the metadata cache. They are not
the same thing.

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

It currently, and will still with 55, require metadata from only *some*
ebuilds (usually just one). You're talking about making it require
metadata from all of the ebuilds.

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

Er, no. It means we only have to consult any file at all for the best
version, and then go backwards down versions until we find a visible
version.

> So what practically are we accomplishing for our users?

We are letting package manager people make the changes needed so that
developers can write better ebuilds.

> And how much developer time would be wasted to do so, and indeed has
> already been wasted on this?

Thanks to emails like yours, lots.

> (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?)

Easily-extractable EAPI either has change scope limitations or a
considerable performance impact.

GLEP 55's getting nowhere because a small group of religious fanatics
are doing anything they can to derail it because it came from "the
wrong people". If you want to know the kind of arguments that are being
thrown against GLEP 55 now, just have a look at:

22:54 < ciaranm> it's been established by precedent that gleps propose
an enhancement, and that competing enhancements get their own gleps
22:55 < bonsaikitten> well, we claim precedent on this one
22:55 < bonsaikitten> so there :)
22:55 < ciaranm> point to your precedent please
22:55 < bonsaikitten> it is the precedent
22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that
means..
22:56 < bonsaikitten> ciaranm: you refuse to accept time travel

Yup, the argument of the week against GLEP 55 is that we refuse to
accept time travel.

-- 
Ciaran McCreesh