Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   RFC: per package eclass GLEP (http://www.linux-archive.org/gentoo-development/429185-rfc-per-package-eclass-glep.html)

Matti Bickel 09-19-2010 07:14 PM

RFC: per package eclass GLEP
 
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.
GLEP: 62
Title: Per package eclasses
Version:
Last-Modified:
Author: Matti Bickel <mabi@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
Post-History:

Abstract
========

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
package.

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.

Specification
=============

The per-package eclasses are specified to be placed directly under the package
directory (as described in [1]_). 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
the function.

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.

Backwards Compatibility
=======================

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" ([1]_). 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.

Copyright
=========

This document has been placed in the public domain.

.. [1] http://distfiles.gentoo.org/distfiles/pms-3.pdf, Section 4.3

"Andreas K. Huettel" 09-19-2010 08:49 PM

RFC: per package eclass GLEP
 
Wouldn't it also make sense to have "per-category eclasses"? This seems much more useful for me.

Examples where this would already make sense today: kde-meta, latex-package, ...

Best, Andreas

On Sunday 19 September 2010 21:14:56 Matti Bickel 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 :)
>
> 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.
>

--
Andreas K. Huettel
Gentoo Linux developer - kde, sci, sunrise
dilfridge@gentoo.org
http://www.akhuettel.de/

Alec Warner 09-19-2010 09:24 PM

RFC: per package eclass GLEP
 
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel <mabi@gentoo.org> 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:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1&r2=1.2

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
reasons.)

>
> 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.

Feedback:
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
harder..actually.)

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.

Editorial:
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
works ;))

Duncan 09-19-2010 10:00 PM

RFC: per package eclass GLEP
 
Matti Bickel posted on Sun, 19 Sep 2010 21:14:56 +0200 as excerpted:

> 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.
>
> Backwards Compatibility
> =======================
>
> 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" ([1]_). 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.

AFAIK these two paragraphs together contradict each other in regard to
eapi.

Given that no set eapi is taken to be eapi=0, and this is proposed as part
of a new eapi, eapi MUST be set before pkg-inherit, if pkg-inherit and
thus per-pkg eclasses are to be used at all. The last sentence of the top
paragraph (of the two) should therefore be rewritten to reflect that
requirement and avoid any confusion.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

"Paweł Hajdan, Jr." 09-20-2010 12:19 PM

RFC: per package eclass GLEP
 
On 9/19/10 9:14 PM, Matti Bickel wrote:
> So, yeah, what do you think? Is it worth it?

I second this GLEP. It seems like it will cleanly replace our hacked
eblits implementations from packages like php, glibc, and possibly more.

Also, it will allow more code sharing between ebuilds, which is good.

Paweł

Alec Warner 09-20-2010 05:30 PM

RFC: per package eclass GLEP
 
On Mon, Sep 20, 2010 at 5:19 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 9/19/10 9:14 PM, Matti Bickel wrote:
>> So, yeah, what do you think? Is it worth it?
>
> I second this GLEP. It seems like it will cleanly replace our hacked
> eblits implementations from packages like php, glibc, and possibly more.
>
> Also, it will allow more code sharing between ebuilds, which is good.

How does it provide more code sharing than the existing system?

Previously I could put code I wanted shared:
1) In a global eclass, which means any ebuild in the tree can likely use it
2) In a pkg eblit

Under the new system I can put the code:

1) In a global eclass, any ebuild can likely use it
2) In a per-package eclass, only one package can use it
3) In a pkg eblit, only one package can use it

Wouldn't taking code from a global eclass and moving it to a
per-package eclass limit code re-use?

-A

>
> Paweł
>
>

Matti Bickel 09-20-2010 09:20 PM

RFC: per package eclass GLEP
 
On 09/20/2010 07:30 PM, Alec Warner wrote:
> Under the new system I can put the code:
>
> 1) In a global eclass, any ebuild can likely use it
> 2) In a per-package eclass, only one package can use it
> 3) In a pkg eblit, only one package can use it

Per package eclasses are pretty much eblits with some PM support thrown in.

> Wouldn't taking code from a global eclass and moving it to a
> per-package eclass limit code re-use?

No, code reuse will stay the same. What I like about the idea is moving
more of the code closer to the ebuild files, tightening it's scope. No
more wondering (as an ebuild author) if and how I could use
php5_2-sapi.eclass - it just wouldn't be there.

I'll answer more points tomorrow, but thanks for your ideas!

"Paweł Hajdan, Jr." 09-21-2010 09:57 AM

RFC: per package eclass GLEP
 
On 9/20/10 7:30 PM, Alec Warner wrote:
> How does it provide more code sharing than the existing system?
>
> Previously I could put code I wanted shared:
> 1) In a global eclass, which means any ebuild in the tree can likely use it

A global eclass is quite heavyweight. It requires a review on
gentoo-dev, is difficult to deprecate, and so on. That's discouraging if
you only want to share 2-3 simple functions used by only one package.

> 2) In a pkg eblit

Which is hacky.

> Wouldn't taking code from a global eclass and moving it to a
> per-package eclass limit code re-use?

No. It lowers the barrier to entry in cases where the shared code is
only useful for one package. It can always be promoted to a global
eclass later (with a proven API).

Paweł

Matti Bickel 09-26-2010 01:07 PM

RFC: per package eclass GLEP
 
On 09/19/2010 10:49 PM, Andreas K. Huettel wrote:
>
> Wouldn't it also make sense to have "per-category eclasses"? This
> seems much more useful for me.

Yes, probably. But it'll be enough getting per-package eclasses in,
right now. I'll revisit this when we finally merge dev-php5 and dev-php.
If other teams want to spin this - just go for it :)

Ciaran McCreesh 09-26-2010 01:22 PM

RFC: per package eclass GLEP
 
On Sun, 26 Sep 2010 15:07:33 +0200
Matti Bickel <mabi@gentoo.org> wrote:
> On 09/19/2010 10:49 PM, Andreas K. Huettel
> > Wouldn't it also make sense to have "per-category eclasses"? This
> > seems much more useful for me.
>
> Yes, probably. But it'll be enough getting per-package eclasses in,
> right now. I'll revisit this when we finally merge dev-php5 and
> dev-php. If other teams want to spin this - just go for it :)

Isn't the amount of work to get per-package eclasses basically the same
as the amount of work to get per-(package and category) eclasses?

--
Ciaran McCreesh


All times are GMT. The time now is 05:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.