Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Date: Fri, 02 Sep 2005 12:28:46
Message-Id: 20050902122709.GA32272@nightcrawler
In Reply to: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness by Paul de Vrieze
1 On Fri, Sep 02, 2005 at 10:53:05AM +0200, Paul de Vrieze wrote:
2 > On Friday 02 September 2005 08:04, Brian Harring wrote:
3 > >
4 > > Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi
5 > > defines revisions of it, in my mind a minor revision of the ebuild 1
6 > > format. Any form of loss of backwards compatability *should* be a
7 > > different format, .ebuild2 for all I care.
8 >
9 > The new proposed format loses backwards compatibility. If there is
10 > backwards compatibility no new format or api version is needed. EAPI
11 > should work on the python level, not only on the level.
13 The two are utterly intertwined.
15 Doesn't matter if portage thinks it's eapi 1 or 2, what matters is if the
16 ebuild*sh env *creates* an eapi 1 or 2 env for execution. Python side
17 just behaves a bit differently, ebuild*sh is where all of the actual
18 execution occurs (and varies dependant on eapi).
20 > > Trying to use EAPI to allow for N different formats into one format is
21 > > wrong from where I sit; you would need a container format for it,
22 > > which ebuild wasn't designed for (nor is it easily extensible to be
23 > > made so I posit).
24 >
25 > No it would state that the eclass is 100% compatible with both by the
26 > formats overlapping and the ebuild not threading outside the overlapped
27 > area.
29 And how is this going to work when it's more then just a split of a
30 func?
32 I'm not saying it can't be done, I'm saying it *shouldn't* be done.
33 It's begging for screwups; relying on portage to pick and choose
34 between eapi levels for an ebuild's execution env dependant on an
35 eclass *requires* the ebuild to be fully compatible to those
36 eapis, same for the eclass author. That's not so easy to do, and will
37 lead to a buttload of case tests of EAPI, which isn't going to improve
38 the code (imo).
40 People aren't going to do it, is my opinion. It's unnecessarily
41 complex with minimal gain; the gain being decreased due to the
42 inherent complexity of
43 A) pulling this off in portage
44 B) comprehending *exactly* what portage will do in each case
45 C) the ebuild/eclass author not only managing to get usage of *one*
46 eapi correct, getting potentially N eapi's correct.
47 D) eclasses that inherit eclasses requiring the same eapi
48 compatability checks
49 E) within two bodies of code, devs keeping seperated in their mind the
50 differences between each eapi, and *never* blurring them.
52 Note I'm not pulling the "everyone else is ignorant" crap that popped
53 up on -dev ml; I'm stating that writing to an api is manual work, and
54 people will screw up on it, just the same as in writing the
55 implementation of that api, *we* will screw up on it.
57 Bugs per line, it's unavoidable. Not advocating that we dumb
58 everything down, advocating we don't add something that (assuming we
59 get it right in implementation) is one hell of a pandora's box from
60 the standpoint of complex ebuilds combined with complex eclasses.
62 That's also not even getting into the fact that what you're proposing,
63 effectively greping EAPI from the file is
65 A) helluva lot slower on regen
66 B) trying to turn ebuilds into a container format. They're not a
67 container format, nor should they be (kitchen sink shouldn't be
68 included).
69 C) core's more then capable of supporting seperated formats; the
70 'container' should be the repository, not jammed within the package
71 data.
72 D) It's a helluva lot easier, and less chance for screwup to just
73 define a new format, use a new extension, and have the repository
74 implementation use a different pkg format for that file.
75 E) New, non eapi=1 style change with a different extension wouldn't
76 even be *seen* by the noncompliant repositories. Helluva lot
77 simpler.
79 Not advocating we define a new format every day; I'm advocating that
80 we define a format (v1), we do tweaks to it, and define a new
81 *seperate* format when we need stuff that is beyond the keen of the
82 existing format. Shifting away from declarative syntax, moving away
83 from bash syntax, etc. If it isn't akin to our existing
84 definition of an ebuild, it's not an ebuild and should *not* be jammed
85 into the ebuild format.
87 It's a new beast, and should be seperated.
89 That's also ignoring the additional interaction of elibs thrown into
90 the mix. If what you're suggesting is implemented, eclasses *and*
91 ebuilds would be litered with
93 if [ "$EAPI" == 2 ]; then
94 eapi2 specific stuff
95 elif [ "$EAPI" == 1]; then
96 eapi1 specific stuff
97 else
98 general, all eapi stuff
99 fi
101 Note that the code above also has a nice hidden bug in it that's not
102 obvious till you think about it; there is no way to predict at the
103 time of the ebuilds writing that EAPI3 will work for the else block,
104 yet logic structures of that sort *will* exist if you open up the N
105 EAPI compatibility for an ebuild/eclass. Any bumping of the potential
106 eapi's for an ebuild/eclass will expose it.
108 That and I'd hope if it were ever implemented, devs would be using
109 functions within the logic block; even with, any non-trivial bit of
110 code is going to get nasty as it's littered with a hundred and one
111 checks of eapi tweaking the flow ever so slightly.
113 It's needlessly complex, and a recipe for disaster.
116 > Take for an example many simple kde applications. Those use the kde
117 > eclass to do all the work and only contain a skeleton of variables
118 > themselves. These ebuilds are compatible with both the current as the
119 > proposed new API. When marked so, they could be used as EAPI=1 as soon as
120 > the kde eclass is ported to EAPI=1. Similarly many eclasses do not
121 > provide src_compile, and as such are compatible with both EAPI versions.
123 Lacking src_compile, they're compatible. They're also quite likely an
124 elib, which is a different beast designed to address the fact that
125 library code of eclasses (true library), should exist outside of the
126 eclass. Eclasses are purely templates for ebuilds, a derived
127 template/class from the base template, that an ebuild uses to avoid
128 defining common chunks of code.
130 Common code blocks, say what eutils/toolchain does are elibs (yes I
131 know about the patch dep on eutils, ignore it for the sake of
132 arguement).
134 > > EAPI's original specification was for handling addition of new funcs,
135 > > different hooks in the ebuild; I prefer it remain as this. The core
136 > > rewrite is format agnostic, if a new format is defined (whether a
137 > > massively managled version of ebuild or flat out new), it's a seperate
138 > > format and should be handled via the core, not via ebuild specific
139 > > package handling.
140 >
141 > EAPI now is going to be used for the above. It can however with very
142 > little effort be made such that future ebuild format revisions are
143 > possible. Also don't be mistaken that splitting out configure and make
144 > stages do need support from the python part.
146 Well aware of the complexities involved in keeping the python and bash
147 side in sync; it's part of the reason I oppose what you're proposing.
149 Change in terminology here btw; eapi (imo) has never been defined as a
150 format revision, it's a change in the portage exported bash api, and
151 how it potentially calls into the api (addition of
152 src_configure).
154 People split off a new format (seperate extension fex) when they no
155 longer can make changes to the api, where grand changes are required.
156 EAPI isn't designed to address that; it's designed to address
157 ebuilds/eclasses requiring new ebuild*sh functionality, addition of a
158 new do* or change to # of phases called.
160 eapi0 -> eapi1 is probably going to be the nastiest change over from
161 where I sit; it's the transition from a totally unversioned ebuild*sh
162 env to one that has saner handling.
164 Total change over of ebuild format, as you're hinting at is not eapi's
165 intention; that's covered by the core being format agnostic, and
166 repository abstractions.
169 > > There's no reason a repository can't hold multiple formats internally;
170 > > the capability is there, use that rather then trying to jam too much
171 > > into EAPI, imo at least.
172 >
173 > How would you suggest to do this then. The ebuilds/eclasses are completely
174 > the same except for their EAPI definition. They also have the same
175 > (file)name. And that is not counting the fact that two files containing
176 > the same is bad design as there will allways be an issue of one file
177 > being updated and the other not.
179 I'm saying we stick with what already occurs in the tree; eclass
180 functionality is either prototyped outside of the tree, and
181 introduced, or an ebuild has the eclass functionality prototyped
182 within it, and that code migrated to the eclass.
184 For example- I've got kde eclass that's eapi0, and want to migrate to
185 eapi1. I break the kde eclass up so it's eapi1 compatible (at the
186 func level), but with the exported src_compile eapi0 so I don't break
187 the existance ebuilds.
189 I then add a shim eclass that *is* eapi1 (calling the chunked kde
190 internals), and migrate pkgs gradually over to it. Once it's fully in
191 use, convert the underlying kde eclass to eapi1 (move the shim code
192 in), leave the shim as indirection, and remove the shim from the
193 testing ebuilds.
195 Or.
197 I want to migrate my kde eclass to eapi1. Like any eclass change, I
198 find what would be affected. I break the kde eclass into eapi1
199 compatible chunks (seperated configure and compile), with a eapi0
200 src_compile that calls both.
202 I then go and clean up the ebuilds that override src_compile, and
203 convert them over to the new funcs in the eclass (bumping the ebuild's
204 eapi in the process). Once they're addressed, all that remains is the
205 ebuilds that use the eclasses exported src_compile; remove the eapi0
206 src_compile shim in the eclass, and set EAPI=1 within the eclass. All
207 ebuilds that rely on the eclass to define eapi and the majority of
208 their code (those that didn't required modification), are now eapi1,
209 as is the eclass.
211 Heading off the "make the eclass eapi 0 and 1 compliant with portage
212 choosing between them", what I'm stating is that the eclass and ebuilds
213 authors do it, they be explicit and manage the conversion themselves
214 (if they see the need to bump to eapiN).
215 They can manage the code and keep it sane, rather then trying to ifdef
216 N different eapis and hoping portage doesn't screw up (it will screw
217 up invariably, as will they in both my solution and yours).
219 Mine just is simpler, from where I sit, less chance of screwups beyond
220 usual bonehead mistakes people always make.
222 Either solution expects ebuild/eclass devs to get it right; having
223 portage somehow swivel the eclass so that it's exported api/env is of
224 a certain eapi expects the devs to have that code working properly,
225 and for a *perfect* implementation that can do this without screwup.
227 It's not realistic, frankly.
228 ~harring