Gentoo Archives: gentoo-council

From: Ryan Hill <dirtyepic@g.o>
To: gentoo-council@g.o
Subject: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009
Date: Sun, 22 Feb 2009 23:15:39
In Reply to: Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009 by Peter Volkov
1 On Fri, 20 Feb 2009 00:11:32 +0300
2 Peter Volkov <pva@g.o> wrote:
4 > That said, technically there are other solutions for this problem,
5 > e.g. 1) it is possible to read one line of defined format from any
6 > file 2) it is possible to make eapi inside ebuild name
7 > (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even
8 > breaking compatibility solution, we could already start using if we
9 > had forgotten about GLEP 55 long time ago...
11 I really don't understand why foo-0.1.eapi3.ebuild is considered an
12 acceptable solution and foo-0.1.ebuild.eapi3 is not.
14 They have the same advantages, arguments about aesthetics aside, and
15 seem to be a much cleaner solution than any other that has been
16 proposed. But the former has one distinct disadvantage that the latter
17 does not: any currently released version of portage does not work
18 correctly with ebuilds having version suffixes it does not recognize.
19 For example, you cannot currently create a Manifest in a package
20 directory containing a file named package-1.0.eapi3.ebuild.
22 We can modify portage, of course, to recognize this suffix, and then
23 wait long enough for that release to trickle down. But later, if we
24 want to add another suffix, -scm perhaps, or something we
25 haven't considered yet, we again have to go through the same process. I
26 thought the reason we introduced EAPI was to free us from this.
28 It may seem a minor gripe, but it doesn't take much imagination to come
29 up with other scenarios where this could become a bigger problem.
31 With a format such as .ebuild.eapiX we would avoid these issues.
32 Portage (without any modifications) will not recognize these files as
33 ebuilds (which is exactly the behaviour we want if it doesn't
34 understand the EAPI), so the format of the version string is moot. We
35 could introduce -scm (or whatever) in EAPI X, and be able to use it
36 immediately.
38 Your argument that the .ebuild file suffix is required by convention
39 does not hold water. Ebuilds are not bash scripts. They are
40 specialized scripts for package management that happen to be written
41 in bash ;). You make the point yourself that if you wanted to implement
42 a new ebuild format or change the language ebuilds are written in, you
43 would change the extension to something else. I'd like to argue that
44 we've already done so twice and I hear number 3 is coming real soon now.
46 > Putting GLEP 55 infinite number of times on council agenda makes me
47 > feel that this issue has something common with perpetuum mobile. At
48 > least I'd like similar resolution from our council as the Royal
49 > Academy of Sciences in Paris did in 1775. It's hard to tell anything
50 > new about GLEP 55 but people still don't like it, so, council,
51 > please, ban it forever and let something else arise.
53 I'm sorry, but until you come up with a better reason than "it's
54 tradition", I'm afraid this will continue to be submitted indefinitely.
55 You will have to provide technical objections why this approach is
56 unacceptable before anyone can come up with something that is.
58 Here is an example, to get you started:
59 If a Manifest is generated using a portage version that supports an
60 EAPI and recognizes a package atom containing a version suffix that
61 was added in that EAPI as an ebuild and thus categorizes it as EBUILD in
62 the Manifest, do portage versions that do not support the EAPI have
63 trouble when they see the entry marked EBUILD for a package atom they
64 think is invalid?
67 --
68 gcc-porting, by design, by neglect
69 treecleaner, for a fact or just for effect
70 wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


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