Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: Zac Medico <zmedico@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
Date: Wed, 14 Mar 2012 02:02:07
Message-Id: 20120314020127.GB7731@localhost
In Reply to: Re: [gentoo-dev] RFD: EAPI specification in ebuilds by Zac Medico
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.
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.
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.
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,
36 Sigh. I'm making no such assumptions, nor would I; it's a stupid line
37 of thought.
39 All of this has to function in the absence of a cache, and that's a
40 core usage scenario.
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.
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.
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`.
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.
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. ;)
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.
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.
84 As I said, I'd like to see some accuracy; not hand wavy buzzwords.
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).
91 ~brian


Subject Author
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Zac Medico <zmedico@g.o>