On Wed, 2011-06-08 at 16:50 +0100, Ciaran McCreesh wrote: > On Wed, 08 Jun 2011 17:43:38 +0200 > Hans de Graaff <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
