Gentoo Archives: gentoo-dev

From: "Dawid Węgliński" <cla@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Wed, 25 Feb 2009 03:53:34
Message-Id: 200902250453.17278.cla@gentoo.org
In Reply to: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by "Petteri Räty"
1 On Tuesday 24 of February 2009 23:21:23 Petteri Räty wrote:
2 > Let's try something new. I would like to get opinions from as many
3 > people as possible about GLEP 55 and alternatives listed here in order
4 > to get some idea what the general developer pool thinks. Everyone is
5 > only allowed to post a single reply to this thread in order to make it
6 > easy to read through. The existing thread should be used for actual
7 > discussion about the GLEP and the alternatives. This should be a useful
8 > experiment to see if we can control ourselves :)
9 >
10 > My notes so far:
11 >
12 > 1) Status quo
13 > - does not allow changing inherit
14 > - bash version in global scope
15 > - global scope in general is quite locked down
16 >
17 > 2) EAPI in file extension
18 > - Allows changing global scope and the internal format of the ebuild
19 > a) .ebuild-<eapi>
20 > - ignored by current Portage
21 > b) .<eapi>.ebuild
22 > - current Portage does not work with this
23 > c) .<eapi>.<new extension>
24 > - ignored by current Portage
25
26 All of this are ok for me, though the first shot is my preffered one since
27 it's the most human readable and the rest would be mostly seen as the package
28 version.
29
30 >
31 > 3) EAPI in locked down place in the ebuild
32 > - Allows changing global scope
33 > - EAPI can't be changed in an existing ebuild so the PM can trust
34 > the value in the cache
35 > - Does not allow changing versioning rules unless version becomes a
36 > normal metadata variable
37 > * Needs more accesses to cache as now you don't have to load older
38 > versions if the latest is not masked
39 > a) <new extension>
40
41 I don't see this as the best solution.
42
43 > b) new subdirectory like ebuilds/
44 > - we could drop extension all together so don't have to argue about
45 > it any more
46 > - more directory reads to get the list of ebuilds in a repository
47
48 Nah. Scanning portage tree in this place would be more painful than it's
49 currently.
50
51 > c) .ebuild in current directory
52 > - needs one year wait
53 >
54 > Regards,
55 > Petteri