1 |
Ciaran McCreesh wrote: |
2 |
> Because your proposal addresses none of the underlying problems which |
3 |
> GLEP 55 was created to solve. |
4 |
|
5 |
As said long ago the glep doesn't tell enough: |
6 |
|
7 |
"The current way of specifying the EAPI in ebuilds is flawed. In order |
8 |
to get the EAPI the package manager needs to source the ebuild, which |
9 |
itself needs the EAPI in the first place. Otherwise it imposes a serious |
10 |
limitation, namely every ebuild, using any of the future EAPIs, will |
11 |
have to be source'able by old package managers and hence there is no way |
12 |
to do any of the following: |
13 |
|
14 |
* Change the behaviour of inherit in any way (for example, to |
15 |
extend or change eclass functionality). |
16 |
* Add new global scope functions in any sane way. |
17 |
* Extend versioning rules in an EAPI - for example, addition of |
18 |
the scm suffix - GLEP54" |
19 |
|
20 |
Let's try to start with a common workflow for the user: |
21 |
- an user with an ancient version of portage syncs |
22 |
- it requires a package |
23 |
- it looks at the cache ($portdir/metadata/cache/) |
24 |
- picks the best entry from the ones showing an eapi it understands |
25 |
- keeps going. |
26 |
|
27 |
Apparently we do not have any issue... |
28 |
|
29 |
Now problems: |
30 |
1- the cache could get a non compatible change |
31 |
2- the user triggers a metadata cache regeneration |
32 |
-> the ebuild is sourced -> portage could fail or do something |
33 |
unpredictable |
34 |
3- overlays do not provide metadata cache |
35 |
4- A package manager different from portage do not use the provided cache. |
36 |
|
37 |
Solutions: |
38 |
1- move the incompatible cache out of ancient portage scope (like in a |
39 |
separate directory) |
40 |
2- The user will get unpredictable behavior, but portage tell you when |
41 |
upgrading is needed... |
42 |
3- you'd have to disable them |
43 |
4- unsupported. |
44 |
|
45 |
Apparently for this side we don't have much to do if we get a valid cache. |
46 |
|
47 |
Ebuilds have to be added to portage so here the workflow for the developer: |
48 |
|
49 |
- new ebuild is sourced |
50 |
- cache is generated |
51 |
- manifest is built |
52 |
|
53 |
In this case we have a problem if the source step is a single one, |
54 |
portage won't know in advance how to behave. |
55 |
|
56 |
So the first step has to be split in two: |
57 |
- first portage discovers which is the eapi version |
58 |
- then behave as defined by the eapi |
59 |
|
60 |
The problem is that right now sourcing is done by having an instructed |
61 |
bash. So the simplest way to get the first step done is parsing the |
62 |
ebuild file with something different like file(1) and then instruct bash |
63 |
and do the parsing. |
64 |
|
65 |
This will solve the issue for the developer. |
66 |
|
67 |
What is proposed in glep-55 seems to aim to solve both issues at the |
68 |
same time (it isn't stated) by switching file extension every time the |
69 |
eapi is changed. This is slightly against the principle of the least |
70 |
surprise and apparently is disliked by enough people to lead the |
71 |
situation to be discussed in the council. |
72 |
|
73 |
The fact the glep itself is too much terse doesn't help acknowledging |
74 |
the problems it aims to solve and the fact it fails to state actual |
75 |
issues that may need a solution doesn't make it worth the effort and |
76 |
disruption it would lead. |
77 |
|
78 |
lu |
79 |
|
80 |
-- |
81 |
|
82 |
Luca Barbato |
83 |
Gentoo Council Member |
84 |
Gentoo/linux Gentoo/PPC |
85 |
http://dev.gentoo.org/~lu_zero |