public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Robert R. Russell" <nahoy_kbiki@hushmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] EAPI 2 policy for portage tree
Date: Wed, 10 Dec 2008 02:46:53 -0600	[thread overview]
Message-ID: <37bb205fdfe69706491ac1e986695704@smtp.hushmail.com> (raw)
In-Reply-To: <493EB554.8010204@gentoo.org>

On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote:
> Robert R. Russell wrote:
> > My personal opinion on this matter is pick one of the following:
> > 1)  perform the bugfix without a version bump and remain at the current
> > EAPI version
> > 2)  perform the bugfix with a version bump and remain at the current EAPI
> > version
> > 3)  perform the bugfix with a version bump and upgrade to the latest EAPI
> > Options 1 and 2 are how most updates are done, the user can mask the
> > latest version or upgrade. Option 3 allows the user to continue using the
> > previous version while they decide to update to a portage version that
> > supports the new EAPI.
>
> The current policy states that ebuilds should only be bumped if the
> installed files change. Changing EAPI from 1 to 2 has no effect outside
> the vdb so the current policy means developers should use option 3.
> There was a bug in stable Portage when EAPI 2 went in the tree that made
> Portage stack trace but that's a problem with Portage not with the
> policy in general.
>
> > I would prefer that option 3 be made policy because I run several ~arch
> > packages that either don't have a stable version (kradio) or have a
> > feature that I need (gentoo-sources), and will not be pushed to stable
> > immediately for various reasons from lack of maintainer time to everybody
> > says it conflicts with major pieces of the system (Firefox 3, 64 bit
> > netscape-flash, and xorg).
>
> Why should we prefer making it a little bit easier for stable users over
> making ~arch users needlessly recompile stuff?
>
> Regards,
> Petteri

My answer is a simple example from my own system. My current system uses a 
motherboard that is around 6 months old and is only correctly supported by 
the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old 
nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I 
am using the latest ~arch xorg-x11. The internal video card isn't even 
recognized by the xf86-video-intel drivers except the ~arch versions. Even 
some of the packages I use for school work such as kile have bugfixes and 
other improvements between the versions in stable and ~arch that are 
important to getting work done. The ability to selectively upgrade only the 
specific packages needed to get a working system is a major strength for 
Gentoo. Why should I have to run more packages from ~arch than I absolutely 
need to? We all know that upgrading more software than absolutely necessary 
will result in bad things happening to a computer.

The easiest solution to the problem with ~arch having the only working 
versions of some packages is to get more of those packages stabilized. But, 
we all know that the manpower required simply doesn't exist.





  reply	other threads:[~2008-12-10 11:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09  0:00 [gentoo-dev] EAPI 2 policy for portage tree Jean-Marc Hengen
2008-12-09  0:09 ` Olivier Crête
2008-12-09  0:11   ` Ciaran McCreesh
2008-12-09  0:25     ` Olivier Crête
2008-12-09  0:29       ` Ciaran McCreesh
2008-12-09  0:43         ` Olivier Crête
2008-12-09  7:07           ` [gentoo-dev] " Duncan
2008-12-09  1:44         ` [gentoo-dev] " Jorge Manuel B. S. Vicetto
2008-12-09  6:36 ` Robert R. Russell
2008-12-09  8:55   ` Graham Murray
2008-12-09 18:13   ` Petteri Räty
2008-12-10  8:46     ` Robert R. Russell [this message]
2008-12-10 13:06       ` Daniel Drake
     [not found]         ` <71869e60a61609948c36be6fb7fa8ab8@smtp.hushmail.com>
2008-12-10 20:07           ` Daniel Drake
2008-12-09 16:57 ` Jan Kundrát

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37bb205fdfe69706491ac1e986695704@smtp.hushmail.com \
    --to=nahoy_kbiki@hushmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox