1 |
On Mon, 23 Feb 2009 00:37:47 +0100 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
> Using either manifests |
4 |
|
5 |
...which doesn't solve the metadata generation problem at all, and |
6 |
which doesn't work with existing package managers... |
7 |
|
8 |
> and or switch sync path is even less invasive |
9 |
|
10 |
...which goes against the whole point of inventing EAPI, and which |
11 |
makes the upgrade path a regular pain in the ass... |
12 |
|
13 |
> if you consider that point raised against the proposal to switch |
14 |
> extensions every time something changes in the ebuild format is that |
15 |
> is misleading. |
16 |
|
17 |
How is it misleading? It shows exactly what's going on. |
18 |
|
19 |
> > But the former has one distinct disadvantage that the latter |
20 |
> > does not: any currently released version of portage does not work |
21 |
> > correctly with ebuilds having version suffixes it does not |
22 |
> > recognize. For example, you cannot currently create a Manifest in a |
23 |
> > package directory containing a file named package-1.0.eapi3.ebuild. |
24 |
> |
25 |
> Portage should warn/die if stray files are present. So the whole |
26 |
> thing looks to me as a way to harness a bug. |
27 |
|
28 |
Portage already can't generate manifests correctly if it doesn't support |
29 |
all EAPIs present... This is obvious; why do you bring up such a |
30 |
blatantly irrelevant argument? |
31 |
|
32 |
> As stated before this eapi had been considered a ugly solution |
33 |
> looking for problems to solve. |
34 |
|
35 |
As stated before, you're talking nonsense. Which part of the long list |
36 |
of problems it was created to solve don't you understand? |
37 |
|
38 |
> > With a format such as .ebuild.eapiX we would avoid these issues. |
39 |
> |
40 |
> Using manifest to have portage validate/invalidate ebuilds works as |
41 |
> well and is completely transparent. |
42 |
|
43 |
...and doesn't solve the metadata generation problem, nor does it work |
44 |
with existing package managers. |
45 |
|
46 |
> Usually in order to get something changed is the burden of the |
47 |
> proponents make it worthy for everybody else. Moreover if the change |
48 |
> causes any annoyance, its usefulness has to be considered superior to |
49 |
> the damage. We got people that annoyed about this proposal that they |
50 |
> stated they'll quit if it is passed. |
51 |
|
52 |
Boo frickin' hoo. It's a technical necessity, and a few malcontents |
53 |
threatening to throw their toys out of the pram need to be told to grow |
54 |
up and deal with reality. |
55 |
|
56 |
> This proposal is in the migration-paths document, why we shouldn't |
57 |
> use a less invasive approach, that is using pretty much the same |
58 |
> principle but doesn't have the shortcoming the extension rename ? |
59 |
|
60 |
Because your proposal addresses none of the underlying problems which |
61 |
GLEP 55 was created to solve. |
62 |
|
63 |
-- |
64 |
Ciaran McCreesh |