On 03/12/2012 01:36 AM, Brian Harring wrote: > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote: >> 1) User downloads an overlay that doesn't provide cache. We want the >> package manager to give a pretty "EAPI unsupported" message, rather than >> spit out some bash syntax errors. > > This criticsm pretty much applies *strictly to the existing > implementation*. It's disenguous busting it in this fashion. > > EAPI as a function explicitly gives it an out before hitting any of > that, eliminating your entire critique. Same goes for parsing it out > of the ebuild, or renaming the extension.
You're assuming that the ebuild calls your eapi() function before it uses any syntax that's unsupported by the user's installed version of bash. > 1) PM still doesn't support that EAPI, looks at the cache/ebuild: > checksums are the same, thus the stored EAPI is trustable, leading to > the PM knowing it still can't process that ebuild and masking it > appropriately. You're assuming that cache is provided by the repo, which is not guaranteed, depending on the source. Even if the cache does exist, then you're assuming it's in a format that the package manager can reliably parse the EAPI from, even though that EAPI may not be supported. That may or may not reliable assumption, and having a pre-defined protocol to directly obtain the EAPI without using the cache is much more reliable. > What I'd like to see, is accuracy in this discussion. Skip the > handwavey "complexity! complexity! complexity!" crap, same for > selective robustness definitions. Past attempts at this discussion > mostly failed due to people pulling crap like this and frankly it just > pisses people off. It's just a symptom of people not abiding by the KISS principle. When you start talking about an approach such as the "eapi() function" approach which introduces lots of unnecessary complexity, it naturally makes the whole discussion more complex and hand-wavey. -- Thanks, Zac
