| 1 |
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote: |
| 2 |
<snip> |
| 3 |
> This mail is about EAPI usage in the portage tree. Let me describe it, |
| 4 |
> with what happened today: I'm running a mostly stable system (91 of 1255 |
| 5 |
> installed packages are unstable), but I test here and there some |
| 6 |
> packages. On of the packages, which I installed and is currently masked |
| 7 |
> unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy |
| 8 |
> with it so far. Today, while updating, portage wanted to downgrade cmake |
| 9 |
> to the stable release, due to all cmake 2.6.x version masked by EAPI 2. |
| 10 |
> The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a |
| 11 |
> bug). My rule of thumb is to only use unstable on none system packages |
| 12 |
> |
| 13 |
<snip> |
| 14 |
> |
| 15 |
> With kind regards, |
| 16 |
> Jean-Marc Hengen, a happy gentoo user |
| 17 |
|
| 18 |
The problem is not that an EAPI 2 supporting portage is unstable or that he is |
| 19 |
using a ~arch version of one particular package, but the during a bugfix the |
| 20 |
maintainer moved the ebuild to EAPI 2 without a version bump forcing |
| 21 |
Jean-Marc to downgrade to the stable version. The question on policy is, can |
| 22 |
a maintainer upgrade an ebuild to the latest EAPI while doing some other |
| 23 |
bugfixing without a version bump? |
| 24 |
|
| 25 |
My personal opinion on this matter is pick one of the following: |
| 26 |
1) perform the bugfix without a version bump and remain at the current EAPI |
| 27 |
version |
| 28 |
2) perform the bugfix with a version bump and remain at the current EAPI |
| 29 |
version |
| 30 |
3) perform the bugfix with a version bump and upgrade to the latest EAPI |
| 31 |
Options 1 and 2 are how most updates are done, the user can mask the latest |
| 32 |
version or upgrade. Option 3 allows the user to continue using the previous |
| 33 |
version while they decide to update to a portage version that supports the |
| 34 |
new EAPI. |
| 35 |
|
| 36 |
I would prefer that option 3 be made policy because I run several ~arch |
| 37 |
packages that either don't have a stable version (kradio) or have a feature |
| 38 |
that I need (gentoo-sources), and will not be pushed to stable immediately |
| 39 |
for various reasons from lack of maintainer time to everybody says it |
| 40 |
conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, |
| 41 |
and xorg). |
Archives