Ciaran McCreesh wrote:
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.
When it isn't?
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...
disable overlays to UPGRADE to the new portage. Not rocket science...
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.
If you are generating the cache you must have a way to know it...
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.
file parses quite well avi and mov, ebuild will be anytime more complex
than that right?
Anyway it isn't a problem since the version of portage doing the work is
supposed to be up to date, if isn't it will be updated first using the
normal user workflow that has already been covered by the cache.
Only an ebuild implementation can parse
ebuilds, and only if it already knows the EAPI.
That is always the case since you are adding an ebuild and you are
supposed to have an up to date portage in order to do that.
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.
Not that much.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
