Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009
Date: Sun, 22 Feb 2009 23:48:09
Message-Id: 20090222234800.29d64b8d@snowcone
In Reply to: Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009 by Luca Barbato
1 On Mon, 23 Feb 2009 00:37:47 +0100
2 Luca Barbato <lu_zero@g.o> wrote:
3 > Using either manifests
4
5 ...which doesn't solve the metadata generation problem at all, and
6 which doesn't work with existing package managers...
7
8 > and or switch sync path is even less invasive
9
10 ...which goes against the whole point of inventing EAPI, and which
11 makes the upgrade path a regular pain in the ass...
12
13 > if you consider that point raised against the proposal to switch
14 > extensions every time something changes in the ebuild format is that
15 > is misleading.
16
17 How is it misleading? It shows exactly what's going on.
18
19 > > But the former has one distinct disadvantage that the latter
20 > > does not: any currently released version of portage does not work
21 > > correctly with ebuilds having version suffixes it does not
22 > > recognize. For example, you cannot currently create a Manifest in a
23 > > package directory containing a file named package-1.0.eapi3.ebuild.
24 >
25 > Portage should warn/die if stray files are present. So the whole
26 > thing looks to me as a way to harness a bug.
27
28 Portage already can't generate manifests correctly if it doesn't support
29 all EAPIs present... This is obvious; why do you bring up such a
30 blatantly irrelevant argument?
31
32 > As stated before this eapi had been considered a ugly solution
33 > looking for problems to solve.
34
35 As stated before, you're talking nonsense. Which part of the long list
36 of problems it was created to solve don't you understand?
37
38 > > With a format such as .ebuild.eapiX we would avoid these issues.
39 >
40 > Using manifest to have portage validate/invalidate ebuilds works as
41 > well and is completely transparent.
42
43 ...and doesn't solve the metadata generation problem, nor does it work
44 with existing package managers.
45
46 > Usually in order to get something changed is the burden of the
47 > proponents make it worthy for everybody else. Moreover if the change
48 > causes any annoyance, its usefulness has to be considered superior to
49 > the damage. We got people that annoyed about this proposal that they
50 > stated they'll quit if it is passed.
51
52 Boo frickin' hoo. It's a technical necessity, and a few malcontents
53 threatening to throw their toys out of the pram need to be told to grow
54 up and deal with reality.
55
56 > This proposal is in the migration-paths document, why we shouldn't
57 > use a less invasive approach, that is using pretty much the same
58 > principle but doesn't have the shortcoming the extension rename ?
59
60 Because your proposal addresses none of the underlying problems which
61 GLEP 55 was created to solve.
62
63 --
64 Ciaran McCreesh

Attachments

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

Replies