Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: RFD: EAPI specification in ebuilds
Date: Sat, 24 Mar 2012 13:23:57
Message-Id: jkkhq7$2fm$
In Reply to: Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds by Kent Fredric
1 Kent Fredric wrote:
2 > On 19 March 2012 14:12, Steven J Long <slong@××××××××××××××××××.uk> wrote:
3 >>
4 >> As for non-bash ebuilds, I have always agreed with antarus that they
5 >> should simply use a different extension. Adding a new extension per
6 >> source language is a *lot* cleaner than one per EAPI.
7 >
8 > Ok: If we take this notion and enshrine it in stone:
9 >
10 > If we assume Bash 4 is a seperate language from Bash 3, as its
11 > syntax-backwards-incompatible, is it fair to suggest that for some
12 > future EAPI which require Bash 4, that the extension change to suit?
13 >
14 I don't agree that it's a separate language: a lot of work goes into keeping
15 BASH backward-compatible, so it's only when you use a new feature that your
16 script will no longer work on an older version. We dealt with the move from
17 bash2 to bash 3 quite well, I thought, and I don't see what's wrong with
18 stipulating support for a new BASH version in a new EAPI: that seems
19 quintessential use of the EAPI mechanism to me.
21 Another example would be use of extglob: as a scripting feature it needs to
22 be enabled before any of the functions or script using it are even parsed,
23 or BASH will bail with a syntax error. Specifying that it is so enabled in
24 an EAPI (which I believe was done a while back) allows the ebuild author to
25 use syntax that would otherwise fall over. Again, the EAPI mechanism works
26 fine, and there is no need for a different extension, even though the syntax
27 accepted has changed.
29 So we already have an example of where syntax changes, not just the
30 available environment, work with an EAPI inside the file, as it should be.
32 > ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the
33 > format is bash, and that '.ebuild4' is bash4 only?
34 >
35 > That way you have a forwards declaration of the syntax/file format
36 > required to parse the file, but no declaration of the EAPI, so you're
37 > not breaking encapsulation.
38 >
39 > This is breaking the direct file==eapi connection, but still
40 > maintaining a loose file<->eapi connection.
41 >
42 > Its /sort/ of like the "one time extension change" proposal, except
43 > its less 'arbitrary' than something like .eb , and it gives us the
44 > future option of changing the suffix again if bash 5 comes out with
45 > different syntax.
46 >
47 > Then we can do
48 >
49 > .ebuild = EAPI 0 - 4 & bash >= 3
50 > .ebuild4 = EAPI5 - 9 & bash >= 4
51 > .ebuild5 = EAPI10 - 15 & bash >= 5
52 >
53 > Thoughts?
54 >
55 As Brian said, you still need an EAPI mechanism, and further you've still
56 leaked metadata that simply doesn't need to be leaked. The only thing that
57 has ever held up adoption of EAPI extraction using a simple EAPI="foo"
58 declaration, matching tree-usage, is the fact that PMS does not specify
59 which characters are allowed in an EAPI name. This was asked for a couple of
60 years ago, iirc, and it is clearly necessary whether you scan for a token in
61 the ebuild, or you stick EAPI into the filename. (After all you are even
62 more restricted when you're talking about the filename, as opposed to a text
63 string given in a script.)
65 It just seems like a major hole in the spec, given that EAPI is so critical
66 to how you deal with the ebuild, and characters allowed for other tokens
67 such as category, package, version, keywords, USE-flags etc are specified.
68 It would be necessary for GLEP-55, but is not mentioned therein, which I
69 guess means the GLEP is under-specified as well.
71 .eapi-NN just strikes me as similar to having M$ Word format as .doc95
72 .doc2000 and the like- a complete mess. Or indeed sticking the charset
73 encoding (which has profound consequences when reading a file) from an HTML
74 file into its filename. Again, a similar, if not worse, piece of metadata--
75 just extracting it is hard if you don't know the charset in advance, but
76 I've never heard of anyone arguing that it should belong anywhere other than
77 in the file, from where tools dealing with it locally can extract it and,
78 say, emit the correct HTTP header.
80 What I was referring to with an extension-per-language would be something
81 like .pbuild for python-based build scripts, or .xbuild for your XML-
82 declarative example, and so on. In each case, you'd still need a supporting
83 infrastructure, but it's clear that you are using a completely different
84 setup, and it's no longer a traditional BASH-based ebuild. It would be quite
85 reasonable to suppose that you'd have EAPI specified there as well, since
86 you'd want to be able to add to and change the features you support over
87 time. Would you really want to change the extension each time you did,
88 though?
90 Regards,
91 Steve.
92 --
93 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)