Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: per package eclass GLEP
Date: Sun, 19 Sep 2010 22:07:38
Message-Id: AANLkTimfzQrr=63-cngW_O8ko4G_BrTko1nDYqZg9QbB@mail.gmail.com
In Reply to: [gentoo-dev] RFC: per package eclass GLEP by Matti Bickel
1 On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel <mabi@g.o> wrote:
2 > I'm a couple weeks late with this, but here goes:
3 > from my failed attempts at reviving GLEP33 grow a discussion with
4 > ferringb on IRC about how to get what I wanted anyway :)
5
6 I've placed my immediate feedback in CVS:
7
8 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1&r2=1.2
9
10 I will split the remaining commentary up into two sections:
11
12 General Idea Feedback (call these non-editor related) and editorial
13 feedback (generally segments you should add to the GLEP for editorial
14 reasons.)
15
16 >
17 > We agreed that having eclasses specific to a package located someplace
18 > near the actual ebuilds was beneficial and should be supported by PMs
19 > somehow. Someplace and somehow are specified along some other details in
20 > the attached proposed GLEP.
21
22 Feedback:
23 I believe the biggest reason to have per-package eclasses is the following:
24
25 1) It limits how users can use an eclass.
26 a) This makes mis-using eclasses harder to do; Interfaces that are
27 hard to use incorrectly are good.
28 b) It means changing an eclass affects fewer packages. It is
29 currently difficult to control eclass consumers in the current model.
30 (anyone can use any eclass.)
31 c) It means eclass changes are easier to test.
32
33 I think the GLEP attempts to over-blow the actual impact that its
34 proposed changes may have. For instance I do not think per-package
35 eclasses will drastically reduce the number of eclasses in the global
36 eclass directory. It will not make overlays easier to use (possibly
37 harder..actually.)
38
39 Plus the number of eclasses that will move to per-package is likely
40 few (the GLEP itself only notes three.)
41
42 >
43 > I'm posting this for review by the wider community, at the same time
44 > asking the GLEP editors (antarus? pva?) for guidance on the formalities.
45 > I gather the GLEP should get a number and be uploaded in CVS somewhere,
46 > as well as appear on the GLEP project page.
47
48 Editorial:
49 The proposal is vaguely similar to GLEP 33. There is also an existing
50 implementation of per-package eclasses called eblits (used in glibc,
51 possibly in other places.) The GLEP should refer to these (link to
52 GLEP 33, if there is a page describing eblits; link to that as well.)
53 The GLEP should also discuss why GLEP 33 and eblits are not the best
54 implementation of this idea.
55
56 If the GLEP makes claims such as 'The implementation will improve X or
57 reduce Y by Z%' the GLEP should cite sources, data, or make some kind
58 of argument as to why that is the case. For instance the GLEP refers
59 to 'distributing ebuilds in overlays will be easier' but fails to
60 discuss how it is easier in this new system. When thinking about
61 these types of things; try to break them down into something
62 measurable. For instance: "With the old system there were 5
63 individual steps, the new system only has 3."
64
65 The GLEP makes claims about how the per-package eclasses *could* be
66 made part of the Manifest format. The GLEP should not focus on could.
67 Either the per-package eclasses are part of the manifest code (per
68 this GLEP) or they are not. If the GLEP dictates they are to be
69 included in manifests the GLEP should discuss how exactly that will
70 work (what types, checksums, etc..) If the eclasses are not required
71 to be manifested then the GLEP should not tout that as an advantage
72 over the status quo.
73
74 >
75 > So, yeah, what do you think? Is it worth it? Can the draft be improved?
76 > I'm specifically interested in the amount of work involved in supporting
77 > something like the thing laid out in the GLEP in our current PMs.
78 >
79
80 Any dev can check stuff into other dev's individual CVS space. Feel
81 free to edit the eclass in my devspace if you wish. I think there is
82 some automation on the actual GLEP webspace now (that htmlifies GLEPS)
83 so I am avoiding that space cause I forgot how exactly the automation
84 works ;))