On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: > > What is proposed in glep-55 seems to aim to solve both issues at the > > same time (it isn't stated) by switching file extension every time the > > eapi is changed. This is slightly against the principle of the least > > surprise and apparently is disliked by enough people to lead the > > situation to be discussed in the council. > > > > Instead of switching file extension every time the eapi is changed you > could also increment it only when a new EAPI breaks sourcing the ebuild > compared to the requirements of the prior EAPI. > (This way you'd in fact split EAPI into a major- and a minor-version.)
Complicates the implementation (annoying), but more importantly negates one of the features of g55- being able to tell via the extension if the manager supports that EAPI. Honestly, the issue isn't breaking sourcing (literally unable to source it) of the ebuild as much as sourcing it *wrong*- simplest example, new metadata key is added in eapi 1.3, compliant implementations have to pull that key out of the env and put it in the cache. Sourcing on the surface, would succeed- but the results would be worthless (it'd basically be similar to the situation now). ~brian
pgpeX8pilTQ8r.pgp
Description: PGP signature
