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
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 :)
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'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.
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.
Title: Per package eclasses
Author: Matti Bickel <firstname.lastname@example.org>
Type: Standards Track
This document proposes a new kind of eclasses, which are specific to a certain
package (hence "per-package eclasses"). It explains the current need for
package specific eclasses, the proposed solution and a possible migration path.
What is proposed is, in short, creation of eclasses in package directories for
use by the ebuilds of the package in the same directory. Per-package eclasses
can be thought of (broadly speaking) as normal eclasses used only by one
Motivation and Rationale
Gentoo currently provides 211 eclasses as of 14-08-2010, 36 of which are marked
"@DEAD" and are scheduled for removal. At least three non-dead eclasses are
specific to one package (mysql, php5_2-sapi and nvidia-drivers). The sheer
number of eclasses makes it hard for old and new developers to quickly find the
eclass they are looking for. Providing overlays and working on a single package
also is not as easy as it should be. Last but not least, eclasses provided in
the package directory could be part of the package's Manifest file, providing
part of the eclass signing the Gentoo tree still lacks.
Placing the package specific eclasses into the package directories themselves
solves all of the problems mentioned (at least partly). It will reduce the
clutter in the current eclass directory, provide a single directory to
understand an ebuild and provides security benefits by including the eclasses in
the Manifest file.
The per-package eclasses are specified to be placed directly under the package
directory (as described in _). The eclass may have any name permissible
for other eclasses (specifically, must end with ".eclass").
A per-package eclass is included in an ebuild by a new function ``pkg-inherit``
called in the global scope of the ebuild.
The ``pkg-inherit`` function must be given zero or more arguments. If no
argument is given, the function shall behave like it was called with the
argument ``default``. It is specified to search the package directory of the
calling ebuild (but no other directories) for eclasses with the names of the
arguments and the suffix ".eclass". If such files exist, they must be sourced by
If not specified otherwise below, the package manager shall treat the
per-package eclass as a normal eclass in any other respect.
It is made a requirement that per-package eclasses can not modify the ``EAPI``
variable. It is assumed ``EAPI``, if it set, is set before calling pkg-inherit.
The current Package Manager Specification requires package managers to ignore
anything in the top-level package directory that does not have a filename ending
in ".ebuild" (_). Thus package manager which do not implement the per-package
eclass feature can ignore them. They, however, will fail to execute ebuilds
making use of the new ``pkg-inherit`` function. It is therefore required this
feature be made part of a new EAPI.
Additionally, tools that regenerate the Manifest file should be aware of
per-package eclasses. However, this is only of concern to developers
regenerating Manifests in a specific package directory. It is assumed that
whoever changes functionality in a package also uses tools capable of supporting
features used in the package's ebuilds.
This document has been placed in the public domain.
..  http://distfiles.gentoo.org/distfiles/pms-3.pdf, Section 4.3