| 1 |
On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> And on what basis would you stabilise Portage, when there are no |
| 4 |
> ebuilds in the tree to test its EAPI 6 code? |
| 5 |
> |
| 6 |
|
| 7 |
As long as the EAPI6 code in the new portage is no more broken than |
| 8 |
the EAPI6 code in the current stable version of portage (which doesn't |
| 9 |
work/exist at all), it isn't much of a regression. What would be more |
| 10 |
of a pain is dealing with fixes in stable. |
| 11 |
|
| 12 |
But, I don't have a problem with starting to use EAPI6 now, mainly |
| 13 |
because the ~arch version of portage does not require any new ~arch |
| 14 |
dependencies that would create a mess for stable users. So, if a user |
| 15 |
needs to switch to a newer portage for a month or two it shouldn't be |
| 16 |
that big of a deal. |
| 17 |
|
| 18 |
Actually, what is less clear to me is how portage versioning actually |
| 19 |
works, or if we attach any meaning to the version numbers at all. |
| 20 |
Both the stable and unstable series are on 2.2.x, but there are no |
| 21 |
versions in the tree between 2.2.20 and 2.2.23. |
| 22 |
|
| 23 |
The main thing I find painful in following ~arch on the odd package is |
| 24 |
when maintainers drop versions quickly after bumping them. That tends |
| 25 |
to result in a situation where if you follow ~arch you end up having |
| 26 |
to accept lots of updates because none of the versions stay in the |
| 27 |
tree long enough to actually get stabilized. Unless a ~arch package |
| 28 |
version is so broken that it could never be stabilized it is probably |
| 29 |
better to leave them there so that it is easier for users to drop back |
| 30 |
from ~arch to stable without downgrading. |
| 31 |
|
| 32 |
-- |
| 33 |
Rich |
Archives