List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel <email@example.com> wrote:
> I'm a couple weeks late with this, but here goes:
> from my failed attempts at reviving GLEP33 grow a discussion with
> ferringb on IRC about how to get what I wanted anyway :)
I've placed my immediate feedback in CVS:
I will split the remaining commentary up into two sections:
General Idea Feedback (call these non-editor related) and editorial
feedback (generally segments you should add to the GLEP for editorial
> We agreed that having eclasses specific to a package located someplace
> near the actual ebuilds was beneficial and should be supported by PMs
> somehow. Someplace and somehow are specified along some other details in
> the attached proposed GLEP.
I believe the biggest reason to have per-package eclasses is the following:
1) It limits how users can use an eclass.
a) This makes mis-using eclasses harder to do; Interfaces that are
hard to use incorrectly are good.
b) It means changing an eclass affects fewer packages. It is
currently difficult to control eclass consumers in the current model.
(anyone can use any eclass.)
c) It means eclass changes are easier to test.
I think the GLEP attempts to over-blow the actual impact that its
proposed changes may have. For instance I do not think per-package
eclasses will drastically reduce the number of eclasses in the global
eclass directory. It will not make overlays easier to use (possibly
Plus the number of eclasses that will move to per-package is likely
few (the GLEP itself only notes three.)
> I'm posting this for review by the wider community, at the same time
> asking the GLEP editors (antarus? pva?) for guidance on the formalities.
> I gather the GLEP should get a number and be uploaded in CVS somewhere,
> as well as appear on the GLEP project page.
The proposal is vaguely similar to GLEP 33. There is also an existing
implementation of per-package eclasses called eblits (used in glibc,
possibly in other places.) The GLEP should refer to these (link to
GLEP 33, if there is a page describing eblits; link to that as well.)
The GLEP should also discuss why GLEP 33 and eblits are not the best
implementation of this idea.
If the GLEP makes claims such as 'The implementation will improve X or
reduce Y by Z%' the GLEP should cite sources, data, or make some kind
of argument as to why that is the case. For instance the GLEP refers
to 'distributing ebuilds in overlays will be easier' but fails to
discuss how it is easier in this new system. When thinking about
these types of things; try to break them down into something
measurable. For instance: "With the old system there were 5
individual steps, the new system only has 3."
The GLEP makes claims about how the per-package eclasses *could* be
made part of the Manifest format. The GLEP should not focus on could.
Either the per-package eclasses are part of the manifest code (per
this GLEP) or they are not. If the GLEP dictates they are to be
included in manifests the GLEP should discuss how exactly that will
work (what types, checksums, etc..) If the eclasses are not required
to be manifested then the GLEP should not tout that as an advantage
over the status quo.
> So, yeah, what do you think? Is it worth it? Can the draft be improved?
> I'm specifically interested in the amount of work involved in supporting
> something like the thing laid out in the GLEP in our current PMs.
Any dev can check stuff into other dev's individual CVS space. Feel
free to edit the eclass in my devspace if you wish. I think there is
some automation on the actual GLEP webspace now (that htmlifies GLEPS)
so I am avoiding that space cause I forgot how exactly the automation