On Wed, 2011-06-08 at 16:50 +0100, Ciaran McCreesh wrote:
> On Wed, 08 Jun 2011 17:43:38 +0200
> Hans de Graaff <graaff@g.o> wrote:
> > That leaves the question what to do with the approach for EAPI=2,3.
> > I'd rather not risk breaking ebuilds by removing this support just
> > for a violation of PMS if there is no real problem exposed by it.
> 
> The 'invariant' restriction on S in PMS is, strictly speaking, stronger
> than it has to be. However, working out exactly what set of weaker
> rules would be ok proved to be too difficult -- historically, Portage
> has had various different behaviours for global scope variables that
> are assigned variable values. Thus, PMS is the way it is there because
> we know for sure that if you follow those rules you're safe; if you
> don't, you'll definitely cause problems for EAPI 4, and you may or may
> not get away with it for earlier EAPIs.
> 
> It's a bit like assuming that it's ok to dereference a null pointer
> and get a zero, since that's what one particular system does...

Thanks for the background on this particular part of the specification.

I think I'll add an eqawarn to the eclass for EAPI=2,3 and migrate
ebuilds over naturally. I'll bump the remaining ones in 6 months or so.
That also gives overlays some time to move to EAPI=4.

Kind regards,

Hans