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
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: RFC: Reviving GLEP33
Date: Fri, 6 Aug 2010 19:34:09 +0100
On Fri, 6 Aug 2010 11:18:46 -0700
Brian Harring <ferringb@...> wrote:
> And by "right now", I assume you meant to say "minimally a year down 
> the line after a portage is stabled supporting g55 semantics and 
> resolving any breakage it's usage induces".  You know, the same issue 
> EAPI itself had to go through to ensure that people had a reasonable 
> chance of getting an appropriate error message and support being in 
> place.

Uh, no, since GLEP 55 doesn't need users to be using a newer Portage.
That is one of the many ways in which it is a much better solution.

> New version formats aren't magically usable the moment g55 lands.  At 
> the very least you're forgetting about bundled glsa's and their 
> knowledge of atom formats.
> 
> Suppose the next comment will be "they suck, throw them out", but so 
> it goes.

No, the fix is to give them EAPI suffixes too.

> Realistically, 'the fact is' that a specific scm tag is preferable to 
> -9999.  The reality is that people and the tools have been working 
> around it without huge issues for a long while.
> 
> Would it be nice having some -scm tag?  Sure.  Is it worth the 
> disruption impementing it, and it's dependencies requires?  That 
> arguement you've still not managed to convince people of.

...and 1.2-3 and 1.2-alpha3 style versions, and so on.

Remember, it's only a disruption to implement it without GLEP 55.

> The restrictions are "no new global functionality can set or
> influence EAPI".  Basically the same restriction you forced on
> eclasses.  It's nasty and arbitrary when I state it, but some how it
> is sane when you propose it the same thing?

No, they're not. The restrictions are "no changes that will make older
package managers not realise that the EAPI was supposed to have been set
to something else". That's not the same thing at all, especially on the
"using new Bash syntax" front, and the very fact that you missed that
point just goes to illustrate the difficulties involved.

> The thing you're ignoring out of this g55 idiocy is that people don't 
> particularly seem to want it.  There has been an extremely vocal 
> subgroup of paludis/exherbo devs pushing for it while everyone else 
> seems to have less than an interest in it.  That's generalizing a
> bit, but is reasonably accurate.

Uh, no. Plenty of people want it. There has been an extremely vocal
subgroup of people who will yell at anything they think is connected to
the 'wrong people' pushing against it, thus making everyone else suffer.

> _EITHER WAY_, rather than having g33 get beat down for unrelated 
> reasons by people screaming they want their pony/g55, g33 can proceed 
> despite claims to the contrary, and it doesn't require g55 as 
> ciaran/crew have claimed.

But no-one except you wants GLEP 33. What people want is per-package
eclasses *without* all the arbitrary restrictions in GLEP 33.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: RFC: Reviving GLEP33
-- Brian Harring
References:
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
-- David Leverton
Re: RFC: Reviving GLEP33
-- Brian Harring
Re: RFC: Reviving GLEP33
-- Brian Harring
Navigation:
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:
Council Agenda 20100809 rev 01


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.