FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-02-2010, 09:56 AM
Matti Bickel
 
Default RFC: Reviving GLEP33

Hi folks,

I've been told that my use of eblits in dev-lang/php is something I
should get rid of as soon as possible. Suggested alternative by ferring:
use elibs.

So here goes: I want to see GLEP33[1] implemented in portage, so I can
shift the eblits core and currently global functions into elibs and
probably push the eblits I use for php into the same structure.

Basic question: what needs to be done to get this GLEP accepted and
implemented (it's current status is moribound)?

I extracted a list of things we (or rather the portage and all other PM
teams) need to do:

(1) create elibs() function to enable importing elibs
(2) extend repoman to handle new style elibs and eclass signing/checking
(3) profit

Also, there're some question I have:
(1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of
"Cases where the constant [metadata] requirement is violated are known"
- who exactly are the current offenders?

(2) What's the dev community feeling on "The end of backwards
compatibility..." section in the GLEP? Personal opinion: when the
council reached consensus that old eclasses can be removed with due
last-rites, this section became obsolete. Just putting new-style
eclasses in their own dirs in eclass/ might again be an option. Please
discuss.

(3) Continuing with (2) do you feel we still need to provide a eclass
compat build (tarball) to users *still* not using a sane portage
version? If no, section "The start of a different phase of backwards
compatibility" can probably be stripped from the GLEP.

I silently assumed that our infra servers are running >=portage-2.1.4.4
here.

Instead of all the backwards-compatibility issues the GLEP deals with,
we could just sneak the implementation into EAPI4 and be done with it.

[1] http://www.gentoo.org/proj/en/glep/glep-0033.html
 
Old 08-02-2010, 11:11 AM
Brian Harring
 
Default RFC: Reviving GLEP33

On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
> Hi folks,
>
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by ferring:
> use elibs.
>
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.
>
> Basic question: what needs to be done to get this GLEP accepted and
> implemented (it's current status is moribound)?
>
> I extracted a list of things we (or rather the portage and all other PM
> teams) need to do:
>
> (1) create elibs() function to enable importing elibs

There's a caveat here; imagine one of the current PM's processing an
EAPI=4 (or whatever) ebuild that uses elib- specifically there will be
a global scope function invocation of a function that doesn't exist.

In the past, a minority of folk have raised complaints about this- it
was never stated as best I know, but my assumption looking back is
that it was due primarily to paludis getting pissy about ebuilds
outputing anything during metadata sourcing (paludis at this point
isn't pissy about it- mainly sinc eclasses can invoke die after all).

Managers should implementat that functionality; orthogonal to it,
we've got a few options for how to deal with an EAPI=4 ebuild being
metadata sourced by a <=EAPI3 PM (meaning, there will be a "command
not found" spat to stderr during sourcing):

1) if 'elib' isn't defined, define it as a no-op w/in a
profile.bashrc. This doesn't work for paludis (they don't do profile
bashrc at all), but works for pkgcore/portage- would silence the
output in the majority basically. This address gentoo-x86, but
cleanly for stand alone repositories.

2) variation of #1, require consuming ebuilds to inherit an eclass
that has the fallback no-op in it, rather than profile. This would
work for paludis, although again, it's gentoo-x86 specific and would
be limited to overlays. All standalone tree's would have to bundle
their own eclass w/ the no-op.

3) glep55; note that I'm purely listing out options here, will leave
the people pushing that glep to advocate it.

4) I should've thought of this a few years back, but frankly another
option is to fix the @!#*ing package managers. They should collect
stdout/stderr output during sourcing, but only output it if the
metadata sourcing resulted in an EAPI the PM supported. If it's an
EAPI the PM doesn't support, it wouldn't know how to write the cache
for the ebuild anyways.

5) ignore that their may be output, and get on with our lives and
implementing features.

From where I'm sitting, #4 should be implemented regardless of what
solution is choosen. Personally, I prefer #1, but #2 is easy enough
to jam in if people really are bother by a couple of overlays making
noise for people running a stale package manager.


Either way, this particular naggle needs a decision.


> (2) extend repoman to handle new style elibs and eclass signing/checking
> (3) profit

I'd suggest breaking this up- specifically try to get elibs in, but do
not bind their timelines/existance to eclass refactoring.


> Also, there're some question I have:
> (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of
> "Cases where the constant [metadata] requirement is violated are known"
> - who exactly are the current offenders?

Talk to vapier- he had some abuses of SLOT rewriting during merging
(nasty hack that only works for portage) last time I knew. Php had
something similar at the time this glep was written, although that's
since been removed.


> (2) What's the dev community feeling on "The end of backwards
> compatibility..." section in the GLEP? Personal opinion: when the
> council reached consensus that old eclasses can be removed with due
> last-rites, this section became obsolete. Just putting new-style
> eclasses in their own dirs in eclass/ might again be an option. Please
> discuss.

The env saving part of that section is no longer relevant, and the
question of how long to keep eclasses around was addressed in the last
council meeting:
http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt

Now, if eclasses2 went forward, how long to keep the old eclass
directory around is a seperate question.


> Instead of all the backwards-compatibility issues the GLEP deals with,
> we could just sneak the implementation into EAPI4 and be done with it.

Exempting tweaking the inherit mechanism to use a new eclass location,
a lot of the env saving bits of that glep are no longer relevant.

My suggestion? Split this into two, elibs, and eclass refactoring.
~brian
 
Old 08-02-2010, 06:16 PM
David Leverton
 
Default RFC: Reviving GLEP33

On 2 August 2010 12:11, Brian Harring <ferringb@gmail.com> wrote:
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>> Hi folks,
>>
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible. Suggested alternative by ferring:
>> use elibs.

There's a couple of hundred lines of repeated metadata between
php-5.3.2 and php-5.3.3 - not identical, but similar enough that there
would be gains from factoring it out, and elibs won't help with that.
Am I understanding correctly in that you didn't use an eclass to avoid
cluttering up the main eclass directory with something specific to
this one package? If so, it sounds like what you really want is
per-package eclasses (maybe with elibs as well to hold the
non-metadata code), which aren't covered by GLEP33 but ought to be
easy enough to add.

> There's a caveat here; imagine one of the current PM's processing an
> EAPI=4 (or whatever) ebuild that uses elib- specifically there will be
> a global scope function invocation of a function that doesn't exist.
>
> In the past, a minority of folk have raised complaints about this- it
> was never stated as best I know, but my assumption looking back is
> that it was due primarily to paludis getting pissy about ebuilds
> outputing anything during metadata sourcing

I can't speak for other people who may have complained, but it seems
to me that for ebuilds to be calling non-existent commands is fairly
obviously wrong, even if the consequences happen to be benign - not
the end of the world, but something that ought to be avoided if
possible. (As far as paludis goes, it's more stdout that it used to
get upset about than stderr.)

> Managers should implementat that functionality; orthogonal to it,
> we've got a few options for how to deal with an EAPI=4 ebuild being
> metadata sourced by a <=EAPI3 PM (meaning, there will be a "command
> not found" spat to stderr during sourcing):
>
> [...]

Regarding the stuff about other standalone repositories, I don't think
it's a big deal to require them to carry a small amount of extra stuff
(only if they actually start using elibs in any case), considering all
the profiles, eclasses etc that they'd need anyway. Overlays based on
the main Gentoo tree would be fine without any effort.

(For the record, +1 for GLEP55 from me, but the reasons for and
against don't need to be repeated yet again.)

> My suggestion? *Split this into two, elibs, and eclass refactoring.

Per-package eclasses would be beneficial IMHO regardless of the other
eclass stuff from 33, might be worth thinking about those as another
item (consistent with the existing design plans of course) if the rest
isn't going to happen soon.
 
Old 08-02-2010, 07:51 PM
Mike Frysinger
 
Default RFC: Reviving GLEP33

On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible.

current eblits support isnt going anywhere. so dont waste time trying to
change code if there is no real alternative. see Bug 327999.
-mike
 
Old 08-02-2010, 08:15 PM
Ciaran McCreesh
 
Default RFC: Reviving GLEP33

On Mon, 02 Aug 2010 11:56:08 +0200
Matti Bickel <mabi@gentoo.org> wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by
> ferring: use elibs.
>
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.

Aren't you really after per-package eclasses, not elibs? Now that
eclasses for installed packages are handled sanely, elibs are just a way
to reduce the metadata generation impact of changing a widely used
eclass, and processors are getting faster faster than the tree is
growing.

> Instead of all the backwards-compatibility issues the GLEP deals with,
> we could just sneak the implementation into EAPI4 and be done with it.

No, you can't make global scope changes just in an EAPI without
screwing up user systems. You have to do the whole "wait several years"
thing for them. If you don't want to screw things up for users, the
only way of avoiding a huge wait for all of this would be to adopt GLEP
55, and of course GLEP 55 won't ever be adopted without years of noise
anyway, so this whole discussion is purely academic.

--
Ciaran McCreesh
 
Old 08-02-2010, 09:40 PM
Matti Bickel
 
Default RFC: Reviving GLEP33

On 08/02/2010 08:16 PM, David Leverton wrote:
> On 2 August 2010 12:11, Brian Harring <ferringb@gmail.com> wrote:
>> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>>> Hi folks,
>>>
>>> I've been told that my use of eblits in dev-lang/php is something
>>> I should get rid of as soon as possible. Suggested alternative by
>>> ferring: use elibs.
>
> There's a couple of hundred lines of repeated metadata between
> php-5.3.2 and php-5.3.3 - not identical, but similar enough that
> there would be gains from factoring it out, and elibs won't help with
> that.

Sure. I was thinking of providing php.eclass with the common metadata
for php-5*, including patchset code, core DEPEND and the like. With the
php team rather stretched nowadays, it will take a few days before
that'll happen. I'm still trying to cope with the complexity of the
whole php eco-system.

> Am I understanding correctly in that you didn't use an eclass to
> avoid cluttering up the main eclass directory with something specific
> to this one package?

Yes. Actually, that was hoffie's goal, when he decided to use eblits.
I continued this and actually made php5_2-sapi.eclass obsolete by using
eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit
for this - the amount of code shared went through the ceiling.

> If so, it sounds like what you really want is per-package eclasses
> (maybe with elibs as well to hold the non-metadata code), which
> aren't covered by GLEP33 but ought to be easy enough to add.

It's actually covered by GLEP33:
http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring

And yes, it's one of it's most obvious advantages. I hate the clutter of
php-* eclasses with passion (I'm aware most of them serve a good purpose).

>> My suggestion? Split this into two, elibs, and eclass
>> refactoring.
>
> Per-package eclasses would be beneficial IMHO regardless of the
> other eclass stuff from 33, might be worth thinking about those as
> another item (consistent with the existing design plans of course) if
> the rest isn't going to happen soon.

If we can get that going asap without waiting, I'm all for it.
 
Old 08-02-2010, 09:47 PM
Matti Bickel
 
Default RFC: Reviving GLEP33

On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible.
>
> current eblits support isnt going anywhere. so dont waste time trying to
> change code if there is no real alternative. see Bug 327999.

Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a
different issue, isn't it? I don't see how elibs are not an alternative
for eblits. What can you do with eblits you can't do with elibs?
 
Old 08-02-2010, 09:55 PM
Matti Bickel
 
Default RFC: Reviving GLEP33

On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> Aren't you really after per-package eclasses, not elibs?

Yes. I don't care whether the snippets may affect metadata. They already
don't (at one time they did, but we got warned that that's illegal -
that's why php-5.3 ebuilds have their metadata folded back into them).

>> Instead of all the backwards-compatibility issues the GLEP deals with,
>> we could just sneak the implementation into EAPI4 and be done with it.
>
> No, you can't make global scope changes just in an EAPI without
> screwing up user systems. You have to do the whole "wait several years"
> thing for them.

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.
 
Old 08-02-2010, 10:10 PM
Mike Frysinger
 
Default RFC: Reviving GLEP33

On Monday, August 02, 2010 17:47:01 Matti Bickel wrote:
> On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> > On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> >> I've been told that my use of eblits in dev-lang/php is something I
> >> should get rid of as soon as possible.
> >
> > current eblits support isnt going anywhere. so dont waste time trying to
> > change code if there is no real alternative. see Bug 327999.
>
> Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a
> different issue, isn't it? I don't see how elibs are not an alternative
> for eblits. What can you do with eblits you can't do with elibs?

i didnt mean to indicate that you shouldnt look at moving forward. progress
is a good thing after all.
-mike
 
Old 08-02-2010, 10:17 PM
David Leverton
 
Default RFC: Reviving GLEP33

On 2 August 2010 22:40, Matti Bickel <mabi@gentoo.org> wrote:
> On 08/02/2010 08:16 PM, David Leverton wrote:
>> If so, it sounds like what you really want is per-package eclasses
>> (maybe with elibs as well to hold the non-metadata code), which
>> aren't covered by GLEP33 but ought to be easy enough to add.
>
> It's actually covered by GLEP33:
> http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring

I interpreted that more as a way to organise the global eclasses, but
yes, it could be used for per-package stuff too. I'd still prefer to
have the eclasses next to the ebuilds they're meant to be used by, but
that's just a detail (and as I say, could easily be added to the GLEP
if anyone else wants it).
 

Thread Tools




All times are GMT. The time now is 09:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org