Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

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 
eclasses.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]