1 |
On Mon, 23 Feb 2009 15:46:24 +0100 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
> >> Apparently we do not have any issue... |
4 |
> > |
5 |
> > ...assuming the metadata cache is valid. That isn't always the case. |
6 |
> |
7 |
> When it isn't? |
8 |
|
9 |
Every now and again (probably after someone changes eutils...), rsync |
10 |
mirrors end up shipping a load of stale metadata for parts of the tree. |
11 |
Portage users probably don't notice, since it just causes a slowdown. |
12 |
|
13 |
> disable overlays to UPGRADE to the new portage. Not rocket science... |
14 |
|
15 |
No no. You're forcing people to switch to ~arch to be able to use |
16 |
overlays. |
17 |
|
18 |
> >> In this case we have a problem if the source step is a single one, |
19 |
> >> portage won't know in advance how to behave. |
20 |
> >> |
21 |
> >> So the first step has to be split in two: |
22 |
> >> - first portage discovers which is the eapi version |
23 |
> > |
24 |
> > ...which it can't do, because it doesn't know the EAPI. |
25 |
> |
26 |
> If you are generating the cache you must have a way to know it... |
27 |
|
28 |
No, we don't. That's the entire frickin' point of GLEP 55, and one |
29 |
that you would do well to understand fully before commenting further. |
30 |
The way we generate metadata now is massively horrible, and only works |
31 |
because there aren't any serious global scope differences between |
32 |
EAPIs. We can't make any global scope changes to future EAPIs because |
33 |
it breaks current metadata generation. Right now it's safe to pretend |
34 |
EAPI 0 until the real EAPI is worked out, but that won't hold in the |
35 |
future -- as soon as global scope changes come along, there's no safe |
36 |
EAPI that can be assumed, even if we didn't have to worry about |
37 |
breaking existing package managers. |
38 |
|
39 |
> >> The problem is that right now sourcing is done by having an |
40 |
> >> instructed bash. So the simplest way to get the first step done is |
41 |
> >> parsing the ebuild file with something different like file(1) and |
42 |
> >> then instruct bash and do the parsing. |
43 |
> > |
44 |
> > file(1) can't parse ebuilds. |
45 |
> |
46 |
> file parses quite well avi and mov, ebuild will be anytime more |
47 |
> complex than that right? |
48 |
|
49 |
It's already *way* more complicated than that. Extracting metadata |
50 |
requires a full bash 3 implementation along with a considerable amount |
51 |
of supporting code. |
52 |
|
53 |
> Anyway it isn't a problem since the version of portage doing the work |
54 |
> is supposed to be up to date, if isn't it will be updated first using |
55 |
> the normal user workflow that has already been covered by the cache. |
56 |
|
57 |
Most users don't run ~arch, and do use overlays. So no, this will affect |
58 |
normal user workflow. |
59 |
|
60 |
> > Only an ebuild implementation can parse |
61 |
> > ebuilds, and only if it already knows the EAPI. |
62 |
> |
63 |
> That is always the case since you are adding an ebuild and you are |
64 |
> supposed to have an up to date portage in order to do that. |
65 |
|
66 |
Again, you're not getting it. Doesn't matter how up to date your |
67 |
package manager is. You can't find out the EAPI unless you already know |
68 |
the EAPI. |
69 |
|
70 |
> >> What is proposed in glep-55 seems to aim to solve both issues at |
71 |
> >> the same time (it isn't stated) by switching file extension every |
72 |
> >> time the eapi is changed. This is slightly against the principle |
73 |
> >> of the least surprise and apparently is disliked by enough people |
74 |
> >> to lead the situation to be discussed in the council. |
75 |
> > |
76 |
> > There's no surprise at all. It's extremely clear. |
77 |
> |
78 |
> Not that much. |
79 |
|
80 |
How is '.ebuild-3' being used to specify version 3 of the ebuild format |
81 |
in the least bit surprising? |
82 |
|
83 |
-- |
84 |
Ciaran McCreesh |