1 |
Ciaran McCreesh wrote: |
2 |
> On Mon, 23 Feb 2009 03:15:03 +0100 |
3 |
> Luca Barbato <lu_zero@g.o> wrote: |
4 |
>> Let's try to start with a common workflow for the user: |
5 |
>> - an user with an ancient version of portage syncs |
6 |
>> - it requires a package |
7 |
>> - it looks at the cache ($portdir/metadata/cache/) |
8 |
>> - picks the best entry from the ones showing an eapi it understands |
9 |
>> - keeps going. |
10 |
>> |
11 |
>> Apparently we do not have any issue... |
12 |
> |
13 |
> ...assuming the metadata cache is valid. That isn't always the case. |
14 |
|
15 |
When it isn't? |
16 |
|
17 |
>> 2- The user will get unpredictable behavior, but portage tell you |
18 |
>> when upgrading is needed... |
19 |
> |
20 |
> Not if the version you'd need to do metadata generation is ~arch it |
21 |
> doesn't. |
22 |
|
23 |
... |
24 |
|
25 |
>> 3- you'd have to disable them |
26 |
> |
27 |
> Yes, tell everyone to disable all the overlays that make use of a few |
28 |
> features only in ~arch package managers... That'll work... |
29 |
|
30 |
disable overlays to UPGRADE to the new portage. Not rocket science... |
31 |
|
32 |
>> In this case we have a problem if the source step is a single one, |
33 |
>> portage won't know in advance how to behave. |
34 |
>> |
35 |
>> So the first step has to be split in two: |
36 |
>> - first portage discovers which is the eapi version |
37 |
> |
38 |
> ...which it can't do, because it doesn't know the EAPI. |
39 |
|
40 |
If you are generating the cache you must have a way to know it... |
41 |
|
42 |
>> The problem is that right now sourcing is done by having an |
43 |
>> instructed bash. So the simplest way to get the first step done is |
44 |
>> parsing the ebuild file with something different like file(1) and |
45 |
>> then instruct bash and do the parsing. |
46 |
> |
47 |
> file(1) can't parse ebuilds. |
48 |
|
49 |
file parses quite well avi and mov, ebuild will be anytime more complex |
50 |
than that right? |
51 |
|
52 |
Anyway it isn't a problem since the version of portage doing the work is |
53 |
supposed to be up to date, if isn't it will be updated first using the |
54 |
normal user workflow that has already been covered by the cache. |
55 |
|
56 |
> Only an ebuild implementation can parse |
57 |
> ebuilds, and only if it already knows the EAPI. |
58 |
|
59 |
That is always the case since you are adding an ebuild and you are |
60 |
supposed to have an up to date portage in order to do that. |
61 |
|
62 |
>> What is proposed in glep-55 seems to aim to solve both issues at the |
63 |
>> same time (it isn't stated) by switching file extension every time |
64 |
>> the eapi is changed. This is slightly against the principle of the |
65 |
>> least surprise and apparently is disliked by enough people to lead |
66 |
>> the situation to be discussed in the council. |
67 |
> |
68 |
> There's no surprise at all. It's extremely clear. |
69 |
|
70 |
Not that much. |
71 |
|
72 |
lu |
73 |
|
74 |
-- |
75 |
|
76 |
Luca Barbato |
77 |
Gentoo Council Member |
78 |
Gentoo/linux Gentoo/PPC |
79 |
http://dev.gentoo.org/~lu_zero |