Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Jose Luis Rivero <yoswink@g.o>
Subject: Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Date: Thu, 16 Oct 2008 14:50:34 +0200
On Tue, Oct 14, 2008 at 06:17:12PM +0200, Marius Mauch wrote:
> On Tue, 14 Oct 2008 10:59:39 +0200
> Jose Luis Rivero <yoswink@g.o> wrote:
> > 
> > EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
> > going to happen when we release new and more feature rich EAPIs), and
> > changes usually come with bugs. The ebuild is committed directly to
> > stable implies bugs in stable, which for me is a no-go.
> 
> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
> cases) you could just reuse the foo-1 ebuild for foo-3.
> 
> If there are major differences between foo-1 and foo-2 not related to
> the EAPI change then the maintainer probably didn't want foo-2 to
> become stable anytime soon, so it's at least questionable if foo-3
> should go straight to stable in the first place.

I was talking about this case, were foo-2 is in testing and is not ready
for stable. It's not questionable to go directly to stable if security is
involved in the process.

> And adding a new version directly to stable always comes with a risk,
> you can't eliminate that completely. It's all about risk assessment,
> and how much work you're willing to do or time you want to spend to
> minimize the risk.

Agree. The question bringing here is: how can we minimize the risk if
this situation appear, where we have an EAPI change between ebuilds in 
stable and testing branch and EAPI in testing can only be managed by
testing PMs.
  
> In the end at least one of the above solutions should work in
> almost every case. It might sometimes cause a bit more work than a bump
> that doesn't involve any EAPI changes, but that's life.

Well, when I think about having to revert eapi changes or having to
make own backports and apply these solutions directly to stable because
we are using some features not supported by stable PMs, I have doubts
if it wouldn't be better to avoid these situations and wait for the PMs
to be stable.

> If you have a real case where both suggested solutions aren't
> realistic I'd like to hear about it, otherwise I think we're wasting
> time making up solutions for a non-existant problem

It's not about realistic, just about how risky the solutions could be to
be in our stable branch. Perhaps I'm being very pessimistic. Leave the 
question here and we will see what happen in the future. 
We'll back to this if needed. 

Thanks.

--
Jose Luis Rivero <yoswink@g.o>
Gentoo/Doc Gentoo/Alpha



References:
Stabilize ebuilds which use EAPIs only supported by ~arch PMs
-- Jose Luis Rivero
Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
-- Donnie Berkholz
Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
-- Jose Luis Rivero
Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
-- Marius Mauch
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Next by thread:
Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Previous by date:
RE: bison/flex extra runtime packages
Next by date:
virtualx eclass


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.