Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Wed, 25 Feb 2009 08:17:09
Message-Id: 20090225091657.1c2ec556@gentoo.org
In Reply to: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by "Petteri R├Ąty"
1 I have no strong opinion about this.
2
3 > 2) EAPI in file extension
4 > - Allows changing global scope and the internal format of the ebuild
5 > a) .ebuild-<eapi>
6 > - ignored by current Portage
7
8 simple, straightforward but ugly
9
10 > b) .<eapi>.ebuild
11 > - current Portage does not work with this
12
13 this only has disadvantages in front of a)
14
15 > c) .<eapi>.<new extension>
16 > - ignored by current Portage
17
18 same as a) but maybe less ugly
19
20 > 3) EAPI in locked down place in the ebuild
21 > - Allows changing global scope
22 > - EAPI can't be changed in an existing ebuild so the PM can trust
23 > the value in the cache
24
25 This doesn't need a locked down place, just some strict way of setting
26 it, like at most one EAPI="constant_string_without_space" so that grep
27 & friends can catch it.
28
29 > - Does not allow changing versioning rules unless version becomes a
30 > normal metadata variable
31
32 I'm not entirely sure about this and would need some real
33 example/argument in order to be convinced
34
35 > * Needs more accesses to cache as now you don't have to load older
36 > versions if the latest is not masked
37
38 true but this "more" would need to be measured and opposed to the
39 number of metadata loads in a dep resolution procedure.
40
41 > a) <new extension>
42
43 doesn't have the one year wait drawback and doesn't mess with pm
44 implementation details (eapi) with package names that shall represent
45 upstream ones.
46
47 > b) new subdirectory like ebuilds/
48 > - we could drop extension all together so don't have to argue about
49 > it any more
50 > - more directory reads to get the list of ebuilds in a repository
51
52 I see no advantage there vs 3.a)
53
54 > c) .ebuild in current directory
55 > - needs one year wait
56
57 That could have been done one year ago and would be done now; I think
58 it's still fine now because I don't expect major behavior changes in
59 the ebuild format within one year.
60
61 To summarize, I would retain 3.a as best solution, having the "usable
62 right now" advantage of current glep55 and keeping the ebuild's file
63 names (more or less) consistent with upstream ones.
64
65 Alexis.

Attachments

File name MIME type
signature.asc application/pgp-signature