On Mon, 08 Jun 2009 19:17:56 +0100 Steven J Long <sl...@rathaus.eclipse.co.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
signature.asc
Description: PGP signature
