1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Petteri Räty wrote: |
5 |
> Let's try something new. I would like to get opinions from as many |
6 |
> people as possible about GLEP 55 and alternatives listed here in order |
7 |
> to get some idea what the general developer pool thinks. Everyone is |
8 |
> only allowed to post a single reply to this thread in order to make it |
9 |
> easy to read through. The existing thread should be used for actual |
10 |
> discussion about the GLEP and the alternatives. This should be a useful |
11 |
> experiment to see if we can control ourselves :) |
12 |
> |
13 |
> My notes so far: |
14 |
> |
15 |
> 1) Status quo |
16 |
> - does not allow changing inherit |
17 |
> - bash version in global scope |
18 |
> - global scope in general is quite locked down |
19 |
|
20 |
I don't want to stick with the status quo since being able to probe |
21 |
the EAPI without sourcing the ebuild is quite useful. Among other |
22 |
things, it allows the package manager to avoid the overhead of |
23 |
sourcing the ebuild in case neither the EAPI nor the cache format is |
24 |
understood, which solves a problem [1] discussed in the thread about |
25 |
adding DIGESTS data to the cache. |
26 |
|
27 |
> 2) EAPI in file extension |
28 |
> - Allows changing global scope and the internal format of the ebuild |
29 |
> a) .ebuild-<eapi> |
30 |
> - ignored by current Portage |
31 |
|
32 |
I'd prefer not to introduce an infinite series of file extensions. |
33 |
To me that just seems too unconventional. |
34 |
|
35 |
> b) .<eapi>.ebuild |
36 |
> - current Portage does not work with this |
37 |
> c) .<eapi>.<new extension> |
38 |
> - ignored by current Portage |
39 |
|
40 |
Either of these is fine with me. |
41 |
|
42 |
> 3) EAPI in locked down place in the ebuild |
43 |
> - Allows changing global scope |
44 |
> - EAPI can't be changed in an existing ebuild so the PM can trust |
45 |
> the value in the cache |
46 |
|
47 |
I think it's alright to change the EAPI in an existing ebuild. Since |
48 |
you can simply parse the EAPI instead of sourcing the ebuild, having |
49 |
a valid cache isn't so important. |
50 |
|
51 |
> - Does not allow changing versioning rules unless version becomes a |
52 |
> normal metadata variable |
53 |
|
54 |
As said by Richard [2], it's alright to change the version rules. |
55 |
Since you can simply parse the EAPI, it's not appreciably less |
56 |
accessible than if the EAPI is embedded in the file name. |
57 |
|
58 |
> * Needs more accesses to cache as now you don't have to load older |
59 |
> versions if the latest is not masked |
60 |
|
61 |
Accessing the cache or parsing the EAPI is relatively inexpensive |
62 |
compared to sourcing the ebuild, so it's not really a problem. |
63 |
Again, once you can parse the EAPI, it's not appreciably less |
64 |
accessible then if the EAPI is embedded in the file name. |
65 |
|
66 |
> a) <new extension> |
67 |
|
68 |
I think a new extension is preferable to a directory. |
69 |
|
70 |
> b) new subdirectory like ebuilds/ |
71 |
> - we could drop extension all together so don't have to argue about |
72 |
> it any more |
73 |
> - more directory reads to get the list of ebuilds in a repository |
74 |
> c) .ebuild in current directory |
75 |
> - needs one year wait |
76 |
|
77 |
You really only need to wait in order to avoid things like warning |
78 |
messages about invalid name/version (if you want to do naming |
79 |
convention changes). If the name/version appear valid, the existing |
80 |
cache entries will prevent the ebuild from being sourced by existing |
81 |
versions of portage (as long as the timestamp of the cache entry |
82 |
matches the timestamp of the ebuild). |
83 |
|
84 |
[1] |
85 |
http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml |
86 |
[2] |
87 |
http://archives.gentoo.org/gentoo-dev/msg_bf3aa0199bb521b263b19b4997a0429c.xml |
88 |
- -- |
89 |
Thanks, |
90 |
Zac |
91 |
-----BEGIN PGP SIGNATURE----- |
92 |
Version: GnuPG v2.0.10 (GNU/Linux) |
93 |
|
94 |
iEYEARECAAYFAkmmKkoACgkQ/ejvha5XGaP+2gCfZvkKYypzKydZ+1+sShQkJKr3 |
95 |
ObAAoNr1r9E9eNRCAisahJyqcu6FDV3S |
96 |
=kj8B |
97 |
-----END PGP SIGNATURE----- |