Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFD: EAPI specification in ebuilds
Date: Mon, 19 Mar 2012 01:11:05
Message-Id: jk610t$svf$
In Reply to: Re: [gentoo-dev] RFD: EAPI specification in ebuilds by Ciaran McCreesh
1 Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that
2 a regex is not required during the scan, and nor is restricting it to the
3 first N lines, though the latter may be desirable and could trivially
4 exclude comment and whitespace-only or empty lines.
6 Ciaran McCreesh wrote:
7 >Michael Orlitzky wrote:
8 >> Fair enough, but aren't you arguing the opposite point with Zac? If
9 >> ebuilds are data, fine, we write EAPI=4 somewhere and be done with
10 >> it. Anything not having that format is out-of-spec.
11 >
12 > The problem is that right now there's no way to determine the format of
13 > the data until you already know the format of the data.
14 Well, we know it's bash.. ;)
16 > We hack around
17 > this by not allowing "drastic" format changes, where "drastic" includes
18 > "using things in newer versions of bash" and "not adding new global
19 > scope commands".
20 >
21 > The question under discussion is whether we a) keep "what format the
22 > data is in" as being part of the data, but impose some strange and
23 > arbitrary conditions on it
24 Stipulating an allowed set of characters is in no way arbitrary, nor
25 strange- we already have similar restrictions on category and package names,
26 versions, keywords and USE flags, for example. Requiring that the EAPI
27 assignment for a bash .ebuild must be a literal (ie EAPI="foo" or EAPI=foo
28 or EAPI='foo') at the start of a line, is not hard to understand; as you
29 said ebuild authors already have to deal with lots of other subtle
30 restrictions. As Marc Schiffbauer said, EAPI "might be the most important
31 constraint in an ebuild at all" (from this and earlier discussion, it's
32 clear that it definitely is) -- ebuild developers have to know about it, and
33 this is a simple, clear restriction. Michał Górny stated: "The most
34 important ebuild variables like EAPI should be readable on sight, without
35 having to lookup random variables, functions etc" and in fact, all ebuilds
36 in the tree already use a string literal- it just makes more sense from a
37 code readability pov, quite apart from anything else.
39 You mentioned indentation in another mail; afaics there is no problem with
40 whitespace at the start of the line.
42 Ensuring EAPI declaration and sourced value match, has value beyond use in
43 EAPI extraction: it's a sanity check that should be performed in any case,
44 way before an ebuild hits the tree.
46 > , b) make a one-time change to have some kind
47 > of 'header' inside the file describing its format that isn't really part
48 > of the data itself, or c) admit that GLEP 55 already solved the problem
49 > and we might as well just fix the issue properly once and for all, even
50 > if GLEP 55's author is considered by some to be one of Satan's little
51 > minions.
52 >
53 Regardless of your past behaviour, my objections to GLEP 55 are, and always
54 have been, technical: it breaks encapsulation, which once implemented cannot
55 be taken back. It results in a mess of filename extensions, which are
56 confusing and irrelevant to end-users, as well as making other tools and
57 scripts trickier to implement; a simple example: a highlighting editor would
58 need to pattern-match the file extension. It's not needed: the simplest,
59 least-invasive alternative already works, and should have been adopted years
60 ago, when the Council asked for alternatives to be tried. The tree is
61 clearly in shape to do so now, though.
63 Package versions have to be in the filename to avoid collisions, and indeed
64 the information is relevant to both end-users and developers. EAPI, while
65 vital to the mangler and of immediate concern to developers, matches neither
66 of those. Since it is of immediate concern, restricting it to a string
67 literal makes sense from both maintenance (which is why it matches tree-
68 usage) and implementation perspectives. And specifying what characters are
69 allowed is a no-brainer; it's odd that that still has not been done, despite
70 it also being a requirement for embedding EAPI in filenames.
72 Your motivation for GLEP-55 states: "In order to get the EAPI the package
73 manager needs to source the ebuild." Given a suitable specification, that
74 isn't the case. repoman checks and explicit documentation are all that's
75 needed beyond that.
77 As for non-bash ebuilds, I have always agreed with antarus that they should
78 simply use a different extension. Adding a new extension per source language
79 is a *lot* cleaner than one per EAPI.
81 Regards,
82 Steve.
83 --
84 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


Subject Author
Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds Kent Fredric <kentfredric@×××××.com>