Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Brian Harring <ferringb@...>
Subject: Re: RFC: Reviving GLEP33
Date: Thu, 5 Aug 2010 20:52:12 -0700
On Thu, Aug 05, 2010 at 07:22:20PM +0200, Matti Bickel wrote:
> On 08/05/2010 05:27 AM, Brian Harring wrote:
> > If a PM encounters an EAPI it doesn't understand/support, by 
> > definition the metadata it tried generating is not usable- the PM 
> > doesn't support that new EAPI thus it has zero clue how to 
> > generate/store metadata appropriately for that EAPI.
> I guess the point here is that we need a stable version of PMs for a
> reasonable time before we switch tree ebuilds to it.
> People will hate me if I use EAPI4 functionality in php ebuilds as soon
> as councils approves EAPI4. Security might want a word with me if it's a
> fast-stable security release.
> But this is orthogonal to GLEP55, afaik.

Glep55 suffers the same, rather than being orthogonal.

Alternatively phrased, you can't start using a new feature until 
support is out there.  So after an EAPI is defined, you've got a month 
or so realistically, and that's assuming portage/friends support the 
EAPI at the time it's minted as official.

> >> Bad. So I guess it's back to ferring's "use a new directory not readable
> >> by old PMs" idea. GLEP55++, but having to wait several months for that
> >> and GLEP33 *on top* is not very motivation for me.
> > 
> > The reason for a new directory was to enforce a new structuring that 
> > was more friendly to changelogs and manifests- due to ECLASSDIR being 
> > documented in PMS (and annoyingly eclass-manpagers being the sole 
> > consumer of it) adding a new eclasses directory should require a EAPI 
> > bump.
> I'm not going to argue that PMS doesn't seem to say anything about the
> content of ECLASSDIR other than that eclasses are stored inside it.
> A new dir is fine with me. Can we have that in EAPI4 or is that already
> being finalized?

EAPI4 is a bit up in the air from where I'm sitting.  Write up 
a proposal (or clean up the g33 glep) and push it- even if you miss 
eapi4 (doubtful), it'll be in the next eapi.

> > As for per package eclasses, I'd personally require accessing the 
> > package eclass being done via a new inherit function- this avoids some 
> > annoying gotchas.  That said, I don't see a reason right now that it 
> > couldn't be added into an EAPI, per the reasons I laid out earlier in 
> > this email.
> Okay, so how can I, as somebody not familiar with PM dev process and
> roadmaps, help in getting this done?

I'd suggest roughly the following-

pkg-inherit ['the per pkg-name'] ; specifically, pkg-inherit 
automatically grabs some commonly named package eclass- or you can 
optionally override the per package eclass to use.

The reason for the option is in transitioning away from an old eclass 
implementation, or having an eclass per major version (assuming the 
major versions warrant a seperate eclass).

Note that '/' and friends should be banned from the invocation, to 
prevent a pkg-inherit from trying to reach into another packages 
pgpu95SAUI3Dc.pgp (PGP signature)
RFC: Reviving GLEP33
-- Matti Bickel
Re: RFC: Reviving GLEP33
-- Ciaran McCreesh
Re: RFC: Reviving GLEP33
-- Matti Bickel
Re: RFC: Reviving GLEP33
-- Brian Harring
Re: RFC: Reviving GLEP33
-- Matti Bickel
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: Reviving GLEP33
Next by thread:
Re: RFC: Reviving GLEP33
Previous by date:
Re: RFC: Reviving GLEP33
Next by date:
Re: RFC: Reviving GLEP33

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.