1 |
On Mon, 23 Feb 2009 03:15:03 +0100 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
> Let's try to start with a common workflow for the user: |
4 |
> - an user with an ancient version of portage syncs |
5 |
> - it requires a package |
6 |
> - it looks at the cache ($portdir/metadata/cache/) |
7 |
> - picks the best entry from the ones showing an eapi it understands |
8 |
> - keeps going. |
9 |
> |
10 |
> Apparently we do not have any issue... |
11 |
|
12 |
...assuming the metadata cache is valid. That isn't always the case. |
13 |
|
14 |
> 2- The user will get unpredictable behavior, but portage tell you |
15 |
> when upgrading is needed... |
16 |
|
17 |
Not if the version you'd need to do metadata generation is ~arch it |
18 |
doesn't. |
19 |
|
20 |
> 3- you'd have to disable them |
21 |
|
22 |
Yes, tell everyone to disable all the overlays that make use of a few |
23 |
features only in ~arch package managers... That'll work... |
24 |
|
25 |
> In this case we have a problem if the source step is a single one, |
26 |
> portage won't know in advance how to behave. |
27 |
> |
28 |
> So the first step has to be split in two: |
29 |
> - first portage discovers which is the eapi version |
30 |
|
31 |
...which it can't do, because it doesn't know the EAPI. |
32 |
|
33 |
> The problem is that right now sourcing is done by having an |
34 |
> instructed bash. So the simplest way to get the first step done is |
35 |
> parsing the ebuild file with something different like file(1) and |
36 |
> then instruct bash and do the parsing. |
37 |
|
38 |
file(1) can't parse ebuilds. Only an ebuild implementation can parse |
39 |
ebuilds, and only if it already knows the EAPI. |
40 |
|
41 |
> What is proposed in glep-55 seems to aim to solve both issues at the |
42 |
> same time (it isn't stated) by switching file extension every time |
43 |
> the eapi is changed. This is slightly against the principle of the |
44 |
> least surprise and apparently is disliked by enough people to lead |
45 |
> the situation to be discussed in the council. |
46 |
|
47 |
There's no surprise at all. It's extremely clear. |
48 |
|
49 |
-- |
50 |
Ciaran McCreesh |