Gentoo Archives: gentoo-dev

From: Josh Saddler <nightmorph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Wed, 25 Feb 2009 21:10:13
Message-Id: 49A5B3A7.4080900@gentoo.org
In Reply to: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by "Petteri Räty"
1 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 > 3) EAPI in locked down place in the ebuild
18 > - Allows changing global scope
19 > - EAPI can't be changed in an existing ebuild so the PM can trust
20 > the value in the cache
21 > - Does not allow changing versioning rules unless version becomes a
22 > normal metadata variable
23 > * Needs more accesses to cache as now you don't have to load older
24 > versions if the latest is not masked
25 > a) <new extension>
26 > b) new subdirectory like ebuilds/
27 > - we could drop extension all together so don't have to argue about
28 > it any more
29 > - more directory reads to get the list of ebuilds in a repository
30 > c) .ebuild in current directory
31 > - needs one year wait
32
33 Leave EAPI inside the ebuild. That's where I want to find it.
34
35 Oh, and as others have mentioned, CVS sucks for file renaming and
36 versions. Yet another reason to leave it inside the ebuild.

Attachments

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