Gentoo Archives: gentoo-dev

From: Jacob Floyd <techgurufloyd+gentoo.lists@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Mon, 09 Mar 2009 13:01:24
In Reply to: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by "Petteri Räty"
1 Hello all,
3 Here are my comments, opinions, and a recommendation regarding "GLEP
4 55" and similar proposals. I've put in 1) A) and a) numbering to
5 differentiate the various lists. Though perhaps long winded, at least
6 check out the Recommendation below.
8 The idea of sticking EAPI in metadata.xml was opposed because of XML
9 overhead, and it's a general purpose file, whereas this would force it
10 to have versioned info. Makes sense to me. Though that was one of the
11 ideas I was toying with because the EAPI really is metadata.
13 ===== Extension =====
14 I don't like the idea of changing the extension because (in part
15 summarizing what some others have said):
17 1) inconsistency is not good (rh/fedora has always been .rpm, debian
18 has had .deb, gentoo has .ebuild) That's also why we prefer tabs over
19 spaces and ordering the variables uniformly (at least on sunrise).
20 It's a consistency issue.
22 2) If you change the extension, it becomes technically more difficult
23 to prevent multiple versions of the same package, thus users probably
24 will be required to start specifieing an EAPI when they want to merge
25 a package, because several devs, perhaps on overlays, will start
26 providing multiple versions of ebuilds in different EAPI.
28 3) #2 brings GLSA into play - Changes may have to be made in packages
29 implementing a variety of eapis creating a greater burden to see what
30 the difference is between these different ebuilds.
32 4) If portage does enforce the single eapi per version, that creates
33 an even bigger problem for other "package managers" which was a
34 problem that this GLEP was trying to address, but ends up making
35 smooth interop even more difficult. Some PMS will support multiple
36 EAPIs and others will say no... Overlays...
38 5) Version bumps are more difficult as you have to worry about the
39 eapi in the file name
41 6) If GLEP 55 goes in without GLEP 60, you may need to add a new key
42 in the Manifest for each new EAPI: EBUILD-1 EBUILD-2 EAPI-2-EBUILD...
43 (or something like that) As it is it's just EBUILD. If/when GLEP 60
44 goes in as well, then you have the issue of, "we changed the name -
45 it's no longer an ebuild, but the manifest says it is" which might be
46 a tad confusing (and inconsistent)
48 ===== In Ebuild =====
49 The idea of leaving EAPI defined in the ebuild has the following setbacks:
51 A) sourcing the ebuild to discover the EAPI enforces a strict global
52 part, which prevents significant changes to inherit amongst other
53 things
55 B) It could break as we migrate to newer versions of bash or perhaps
56 "ebuilds" or equivalents that might be in another language (who knows)
58 C) Having a spot locked down in an ebuild to search for EAPI brings a
59 migration drawback, as current ebuilds have something else on line 4
60 or line 5 or whatever, and a potentially erroneous value could be
61 returned for EAPI
63 D) Sourcing the ebuild twice brings a lot of overhead significantly
64 slowing an already (many times) slow process (especially when you
65 imagine KDE and other packages that take a while to compile - 6
66 seconds extra for each package - *shiver*). And it's ugly to have to
67 do it twice.
69 E) EAPI really is metadata and doesn't should be accessible before
70 sourcing the ebuild.
72 ===== Recommendation =====
73 OK. Now for a slightly different solution, or a twist on the other
74 solutions if you will:
76 Stick EAPI info in the Manifest. The Manifest stores metadata info
77 about the ebuilds for security and validation purposes, why not add a
78 string that determines which eapi to use? This then would be generated
79 every time someone did an "ebuild foo-1.0.ebuild digest". To specify
80 the eapi version, the developer would specify, as is now, EAPI="bla"
81 in his ebuild, and grep or similar would be used to extract this when
82 the digest is created. The above mentioned points compare with this
83 solution (as I see it) as follows:
85 -1) Preserves .ebuild allowing for changes if a move were ever made to
86 some other format (who knows: python, or
87 some-cool-new-script-that-beats-bash-by-a-long-shot)
88 -2) Does not change the extension
89 -3) Ditto
90 -4) Ditto
91 -5) Version bumps might take a fractoin longer, as an additional grep
92 is added to the digest process... but arch maintainers shouldn't have
93 a problem with that. (I'm not an arch maintainer, mind you. I'm not
94 even @g.o)
95 -6) This takes care of any Manifest issue, because eapi'll be defined
96 to start off with in the Manifest in a uniform manner
98 -A) No need to source the ebuild twice, just grab the variable from
99 the manifest in the normal execution of digest verification. However
100 if the digest is wrong, or the Manifest doesn't exist or whatever,
101 that is an error and error handling will need to be introduced to grep
102 the EAPI at this point if regenerating the digest is needed/requested
103 -B) A new EAPI would be introduced for such "new" versions of bash and
104 if there were other formats (as in, not bash) they really should get
105 their own extension anyway, but we need some uniform way to grep it
106 and grab the info, or if it can't be found assume that it's EAPI 0
107 -C) It wouldn't have to be on a specific line, though no logic could
108 be used to determine the EAPI (eg no: if use bla; then EAPI="bla"; fi)
109 But it's not used that way right now anyway.
110 -D) This removes the overhead issues of leaving it in the ebuild.
111 -E) The dev specifies it in their ebuild, but it's put in the Manifest
112 where metadata about ebuilds belongs.
114 Now, as far as mitigating migration issues with old PMS that want to
115 use the old inherit, let them =) :
117 ### Imaginary ebuild snippet ###
118 EAPI="NewFoo"
119 inherit eapi
120 inherit2 eutils mypkg.local whatever
121 new_func() {
122 #and other stuff that isn't in eapi 0-2 only in the fancy
123 "NewFoo" EAPI I just invented.
124 if pig and oink; then ewarn "You're in a barnyard, watch your
125 step! If flames went up, this list wouldn't like it."; fi
126 }
127 new_func pig oink
128 ### Imaginary ebuild snippet ###
130 ===== Explanation =====
131 Create a new eapi.eclass that smoothes migration.
133 a) You can have it eerror or ewarn or something to let the user know
134 they need to upgrade to a new version of portage, or file a bug report
135 with their PMS to support the new EAPI ${EAPI} that is used by this
136 package.
138 b) Such an eclass can implement a bogus inherit2 which would allow
139 older PMS to at least sort of finish sourcing the ebuild.
141 c) it could die gracefully on known problematic PMS (yes, a die in the
142 global scope - but it would be the one exception in the entire portage
143 tree - ebuilds still would not be allowed to put die in the global
144 scope, and pre-"inherit eapi" (not pre-inherit2) lines in the ebuild
145 would still have to conform to EAPI 0 specs, but everything after that
146 point would be the new eapi spec.
148 d) It's a graceful stop-gap to help relieve stress due to users not
149 upgrading in 2 or 3 years or whatever might happen, it'll give them a
150 smoother upgrade path.
152 e) at some point when it's determined that users don't need such an
153 eclass anymore, nearly everyone has upgraded or whatever, the eclass
154 could be changed/removed/whatever/I don't know. But until such a
155 point, would include placeholder functions for new "functions"
156 unimplemented in older PMS.
158 f) if an eapi implements features in the global scope that are
159 drastically different from one eapi to the other, the function could
160 simply put a DEPEND on the newer portage version, and display a
161 message that portage will be updated and then they'll need to
162 re-emerge the package, or something like that.
165 inherit2 would be a new fangled inherit can do whatever you want, and
166 would be an dev-opt in type thing, the original inherit could, in
167 theory, be used to inherit other eclasses, but those eclasses would
168 also be restricted to EAPI 0 (or EAPI 1, 2 with proper "if [[ ${EAPI}"
169 sniffing) specs, wheras ebuilds in inherit2 would not have that
170 restriction and could use the newfangled features.
173 Anyway, there's my 2 cents. What do you all think?
174 Jacob Floyd
175 (on irc in some channels: techgurufloyd)


Subject Author
[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives Duncan <1i5t5.duncan@×××.net>