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