1 |
On Mon, Mar 12, 2012 at 09:05:26AM -0700, Zac Medico wrote: |
2 |
> On 03/12/2012 01:36 AM, Brian Harring wrote: |
3 |
> > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote: |
4 |
> >> 1) User downloads an overlay that doesn't provide cache. We want the |
5 |
> >> package manager to give a pretty "EAPI unsupported" message, rather than |
6 |
> >> spit out some bash syntax errors. |
7 |
> > |
8 |
> > This criticsm pretty much applies *strictly to the existing |
9 |
> > implementation*. It's disenguous busting it in this fashion. |
10 |
> > |
11 |
> > EAPI as a function explicitly gives it an out before hitting any of |
12 |
> > that, eliminating your entire critique. Same goes for parsing it out |
13 |
> > of the ebuild, or renaming the extension. |
14 |
> |
15 |
> You're assuming that the ebuild calls your eapi() function before it |
16 |
> uses any syntax that's unsupported by the user's installed version of bash. |
17 |
|
18 |
A bit, although that's a pretty valid assumption frankly. For current |
19 |
bash syntax, the only thing they could do that would cause issues is |
20 |
bash regex's for example- which if they have regex's prior to the eapi |
21 |
invocation, they're doing something stupid anyways. |
22 |
|
23 |
Regardless, detecting and suppressing isn't too hard- start sourcing |
24 |
w/ `set -e`, disabling that once `eapi` has been invoked for example. |
25 |
Pretty sure people will scream "that's horrible", but it's |
26 |
surprisingly effective. |
27 |
|
28 |
|
29 |
> > 1) PM still doesn't support that EAPI, looks at the cache/ebuild: |
30 |
> > checksums are the same, thus the stored EAPI is trustable, leading to |
31 |
> > the PM knowing it still can't process that ebuild and masking it |
32 |
> > appropriately. |
33 |
> |
34 |
> You're assuming that cache is provided by the repo, |
35 |
|
36 |
Sigh. I'm making no such assumptions, nor would I; it's a stupid line |
37 |
of thought. |
38 |
|
39 |
All of this has to function in the absence of a cache, and that's a |
40 |
core usage scenario. |
41 |
|
42 |
|
43 |
> which is not |
44 |
> guaranteed, depending on the source. Even if the cache does exist, then |
45 |
> you're assuming it's in a format that the package manager can reliably |
46 |
> parse the EAPI from, even though that EAPI may not be supported. That |
47 |
> may or may not reliable assumption, and having a pre-defined protocol to |
48 |
> directly obtain the EAPI without using the cache is much more reliable. |
49 |
|
50 |
This is a nonstatement. To deal w/ the cache (validate it) you have |
51 |
to be able to reliably pull EAPI out of the ebuild. |
52 |
|
53 |
That's what this whole fucking discussion is about; really not sure |
54 |
why you're trying to argue this point against eapi as a function. As |
55 |
I already laid out, it can deal w/it, same as the rest. Importantly, |
56 |
the approach can also work across the transition period preventing |
57 |
current-day PMs (using current EAPI mechanisms) from breaking when |
58 |
used against later EAPIs that were released via `eapi as a function`. |
59 |
|
60 |
|
61 |
> > What I'd like to see, is accuracy in this discussion. Skip the |
62 |
> > handwavey "complexity! complexity! complexity!" crap, same for |
63 |
> > selective robustness definitions. Past attempts at this discussion |
64 |
> > mostly failed due to people pulling crap like this and frankly it just |
65 |
> > pisses people off. |
66 |
> |
67 |
> It's just a symptom of people not abiding by the KISS principle. When |
68 |
> you start talking about an approach such as the "eapi() function" |
69 |
> approach which introduces lots of unnecessary complexity, it naturally |
70 |
> makes the whole discussion more complex and hand-wavey. |
71 |
|
72 |
With respect; you're proposing we go gum up version parsing via |
73 |
shoving EAPI directly into it. Literally, make what is already a |
74 |
complex mess, worse. Apply some KISS to your proposal please. ;) |
75 |
|
76 |
Just hammering the point home; compatibility *is* complex. Claiming |
77 |
otherwise is naive. Case in point: your proposal breaks the shit out |
78 |
of any current-day package manager that saw such a filename. |
79 |
|
80 |
I really have a hard time reading your posts when basic issues like |
81 |
that aren't paid attention to, but you've no problems claiming |
82 |
complexity/brokenness in other proposals. |
83 |
|
84 |
As I said, I'd like to see some accuracy; not hand wavy buzzwords. |
85 |
|
86 |
I'd much more like to see prototypes of peoples proposals in addition |
87 |
since at least that way they would flush out the breakages in their |
88 |
proposals (potentially dropping it in the process since some of these |
89 |
are pretty half baked). |
90 |
|
91 |
~brian |