Ciaran McCreesh <ciaran.mccre...@googlemail.com> posted 20090517015039.2fa04...@snowmobile, excerpted below, on Sun, 17 May 2009 01:50:39 +0100:
> On Sun, 17 May 2009 00:35:45 +0000 (UTC) Duncan <1i5t5.dun...@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
