1 |
Hi! |
2 |
|
3 |
On Sat, 16 May 2009, Ciaran McCreesh wrote: |
4 |
> Tobias Klausmann <klausman@g.o> wrote: |
5 |
> > > Yes, those. The current rules include some pointless arbitrary |
6 |
> > > restrictions that are only there for historical reasons and that |
7 |
> > > mean people have to mess with convoluted MY_PV things. |
8 |
> > |
9 |
> > Still: a sane spec for those plus a sane spec for inside-the-file |
10 |
> > EAPI specs can be done with/during *one* extension change. |
11 |
> |
12 |
> GLEP 55's just one extension change: it moves from .ebuild |
13 |
> to .ebuild-EAPI. |
14 |
|
15 |
So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for |
16 |
EAPI=3 etc? That would just be silly and it was the first idea I |
17 |
got when I saw the proposal. |
18 |
|
19 |
Also, I think there might be better options for the new |
20 |
extensions (.gbuild?, just a random idea). |
21 |
|
22 |
Aside from that, one idea that came to me recently was to specify |
23 |
per tree what kind of files (version-format-wise, EAPI |
24 |
elsewhere[0]) a PM has to expect. Tree distributors (Gentoo |
25 |
itself, other similar distros, overlays... ) would be Providing |
26 |
that information along a similar route as profiles/repo_name. |
27 |
This would also reduce the amount of mixing and matching version |
28 |
formats (something undesirable, if you ask me). It would also |
29 |
make it easier to take a look at historical (snapshots of) |
30 |
repositories. |
31 |
|
32 |
[0] I see EAPI specification and version-format spec as separate |
33 |
issues. |
34 |
|
35 |
> > Any further features that mandate a change in filename format? |
36 |
> > Pile them on. |
37 |
> |
38 |
> There probably will be, and we don't know what they all are yet. |
39 |
> Unfortunately we can't see the future. |
40 |
|
41 |
I meant further as in "not discussed yet". |
42 |
|
43 |
Regards, |
44 |
Tobias |
45 |
-- |
46 |
Found on a small utility knife in MIT's lab supply: |
47 |
"Caution. Blade is sharp. Keep out of children." |