On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato <lu_z...@gentoo.org> wrote: > Let's try to start with a common workflow for the user: > - an user with an ancient version of portage syncs > - it requires a package > - it looks at the cache ($portdir/metadata/cache/) > - picks the best entry from the ones showing an eapi it understands > - keeps going. > > Apparently we do not have any issue...
...assuming the metadata cache is valid. That isn't always the case. > 2- The user will get unpredictable behavior, but portage tell you > when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. > 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... > In this case we have a problem if the source step is a single one, > portage won't know in advance how to behave. > > So the first step has to be split in two: > - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. > The problem is that right now sourcing is done by having an > instructed bash. So the simplest way to get the first step done is > parsing the ebuild file with something different like file(1) and > then instruct bash and do the parsing. file(1) can't parse ebuilds. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. > 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. There's no surprise at all. It's extremely clear. -- Ciaran McCreesh
signature.asc
Description: PGP signature
