1 |
Ryan Hill wrote: |
2 |
> On Fri, 20 Feb 2009 00:11:32 +0300 |
3 |
> Peter Volkov <pva@g.o> wrote: |
4 |
> |
5 |
>> That said, technically there are other solutions for this problem, |
6 |
>> e.g. 1) it is possible to read one line of defined format from any |
7 |
>> file 2) it is possible to make eapi inside ebuild name |
8 |
>> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even |
9 |
>> breaking compatibility solution, we could already start using if we |
10 |
>> had forgotten about GLEP 55 long time ago... |
11 |
> |
12 |
> I really don't understand why foo-0.1.eapi3.ebuild is considered an |
13 |
> acceptable solution and foo-0.1.ebuild.eapi3 is not. |
14 |
|
15 |
I guess that principle of the least surprise counts there. |
16 |
|
17 |
> They have the same advantages, arguments about aesthetics aside, and |
18 |
> seem to be a much cleaner solution than any other that has been |
19 |
> proposed. |
20 |
|
21 |
Using either manifests and or switch sync path is even less invasive if |
22 |
you consider that point raised against the proposal to switch extensions |
23 |
every time something changes in the ebuild format is that is misleading. |
24 |
|
25 |
> But the former has one distinct disadvantage that the latter |
26 |
> does not: any currently released version of portage does not work |
27 |
> correctly with ebuilds having version suffixes it does not recognize. |
28 |
> For example, you cannot currently create a Manifest in a package |
29 |
> directory containing a file named package-1.0.eapi3.ebuild. |
30 |
|
31 |
Portage should warn/die if stray files are present. So the whole thing |
32 |
looks to me as a way to harness a bug. |
33 |
|
34 |
> We can modify portage, of course, to recognize this suffix, and then |
35 |
> wait long enough for that release to trickle down. But later, if we |
36 |
> want to add another suffix, -scm perhaps, or something we |
37 |
> haven't considered yet, we again have to go through the same process. I |
38 |
> thought the reason we introduced EAPI was to free us from this. |
39 |
|
40 |
As stated before this eapi had been considered a ugly solution looking |
41 |
for problems to solve. |
42 |
|
43 |
> With a format such as .ebuild.eapiX we would avoid these issues. |
44 |
|
45 |
Using manifest to have portage validate/invalidate ebuilds works as well |
46 |
and is completely transparent. |
47 |
|
48 |
> Portage (without any modifications) will not recognize these files as |
49 |
> ebuilds (which is exactly the behaviour we want if it doesn't |
50 |
> understand the EAPI), so the format of the version string is moot. We |
51 |
> could introduce -scm (or whatever) in EAPI X, and be able to use it |
52 |
> immediately. |
53 |
|
54 |
|
55 |
> I'm sorry, but until you come up with a better reason than "it's |
56 |
> tradition", I'm afraid this will continue to be submitted indefinitely. |
57 |
> You will have to provide technical objections why this approach is |
58 |
> unacceptable before anyone can come up with something that is. |
59 |
|
60 |
Usually in order to get something changed is the burden of the |
61 |
proponents make it worthy for everybody else. Moreover if the change |
62 |
causes any annoyance, its usefulness has to be considered superior to |
63 |
the damage. We got people that annoyed about this proposal that they |
64 |
stated they'll quit if it is passed. |
65 |
|
66 |
> Here is an example, to get you started: |
67 |
> If a Manifest is generated using a portage version that supports an |
68 |
> EAPI and recognizes a package atom containing a version suffix that |
69 |
> was added in that EAPI as an ebuild and thus categorizes it as EBUILD in |
70 |
> the Manifest, do portage versions that do not support the EAPI have |
71 |
> trouble when they see the entry marked EBUILD for a package atom they |
72 |
> think is invalid? |
73 |
|
74 |
Manifest2 is backward compatible to manifest1 by ignoring lines it |
75 |
couldn't parse, so if we have portage embed the eapi information there |
76 |
we'd archive the same result being completely transparent. |
77 |
|
78 |
This proposal is in the migration-paths document, why we shouldn't use a |
79 |
less invasive approach, that is using pretty much the same principle but |
80 |
doesn't have the shortcoming the extension rename ? |
81 |
|
82 |
lu |
83 |
|
84 |
-- |
85 |
|
86 |
Luca Barbato |
87 |
Gentoo Council Member |
88 |
Gentoo/linux Gentoo/PPC |
89 |
http://dev.gentoo.org/~lu_zero |