[gentoo-dev] Re: The fallacies of GLEP55

[Duncan <1i5t5.duncan@cox.net>]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090517015039.2fa0468a@snowmobile, excerpted below, on  Sun, 17 May 2009
01:50:39 +0100:

> On Sun, 17 May 2009 00:35:45 +0000 (UTC) Duncan <1i5t5.duncan@cox.net>
> wrote:
>> As for ciaranm's argument that you're restricting changes to the
>> version string, say allowing -rc where _rc is now required, one-time
>> restriction of a year or two, yes.  However, if the spec is crafted
>> such that the EAPI must be checked FIRST
> 
> ...then the package manager has to inspect the metadata for every
> version of a package before it can do anything, rather than just
> starting at the best version and working downwards until it finds
> something usable, which is a pretty hefty price to pay.

I'd argue that uncached, certainly, it's a heavy price to pay, tho that's 
so slow as to be hardly workable anyway.

Cached, however, while it's certainly a bit of an increase over the 
current price, I don't believe it inordinately so.  Given that for EAPIs 
the PM doesn't understand it bales anyway, ignoring them, and that EAPI 
is defined as FIRST to be determined, it's an early-out in the can't-deal-
with-it case, and scaled against dependency calculation, grabbing the 
EAPI and establishing a proper ordering shouldn't be /that/ much of a 
cost increase, particularly when the alternative is establishing an 
order, then finding we can't deal with the EAPI of the top of the list 
anyway, so we have to reject it.  It's simply putting EAPI rejection 
earlier in the sequence, dealing with that before establishing order and 
immediately rejecting what we can't handle, rather than establishing 
order first, then checking EAPI and possibly rejecting some versions.

So I believe the cost to be quite reasonably managed, after all.  
Benchmarks would of course be needed to demonstrate that, but I believe 
it worth pursuing.

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