1 |
On Wed, 2011-06-08 at 16:50 +0100, Ciaran McCreesh wrote: |
2 |
> On Wed, 08 Jun 2011 17:43:38 +0200 |
3 |
> Hans de Graaff <graaff@g.o> wrote: |
4 |
> > That leaves the question what to do with the approach for EAPI=2,3. |
5 |
> > I'd rather not risk breaking ebuilds by removing this support just |
6 |
> > for a violation of PMS if there is no real problem exposed by it. |
7 |
> |
8 |
> The 'invariant' restriction on S in PMS is, strictly speaking, stronger |
9 |
> than it has to be. However, working out exactly what set of weaker |
10 |
> rules would be ok proved to be too difficult -- historically, Portage |
11 |
> has had various different behaviours for global scope variables that |
12 |
> are assigned variable values. Thus, PMS is the way it is there because |
13 |
> we know for sure that if you follow those rules you're safe; if you |
14 |
> don't, you'll definitely cause problems for EAPI 4, and you may or may |
15 |
> not get away with it for earlier EAPIs. |
16 |
> |
17 |
> It's a bit like assuming that it's ok to dereference a null pointer |
18 |
> and get a zero, since that's what one particular system does... |
19 |
|
20 |
Thanks for the background on this particular part of the specification. |
21 |
|
22 |
I think I'll add an eqawarn to the eclass for EAPI=2,3 and migrate |
23 |
ebuilds over naturally. I'll bump the remaining ones in 6 months or so. |
24 |
That also gives overlays some time to move to EAPI=4. |
25 |
|
26 |
Kind regards, |
27 |
|
28 |
Hans |