| 1 |
Hi. I used to think it was safe to use ~arch packages (through |
| 2 |
package.keywords) on a stable system until I saw bug #257047 - GCC 4.3 |
| 3 |
didn't have a strict enough glibc dependency. And comment #15 in that |
| 4 |
bug report is: |
| 5 |
"[...] we don't test or support half-stable half-testing toolchains, and they |
| 6 |
are likely to break, like in this case. if you're going to use an ~arch |
| 7 |
keyworded complier, you will need to use a ~arch libc." |
| 8 |
|
| 9 |
OK, I will avoid ~arch toolchain components. What worries me is that I |
| 10 |
never saw a warning about this. |
| 11 |
|
| 12 |
Also, GCC 4.3.3 enables FORTIFY_SOURCE=2 by default and this breaks some |
| 13 |
packages. A developer said on 2009-04-10 they were only processing bugs |
| 14 |
that can be confirmed in ~arch. So an arch system with ~arch toolchain |
| 15 |
could hit many bugs and maybe such a system would even be less reliable |
| 16 |
than an entirely ~arch system. |
| 17 |
|
| 18 |
So: |
| 19 |
1) Certain subsystems, like the toolchain, need to be "harmonious" - |
| 20 |
either all arch or all ~arch. What other subsystems have this need? |
| 21 |
|
| 22 |
2) With the FORTIFY_SOURCE issues, it seems that an ~arch toolchain |
| 23 |
shouldn't be used in an arch system at all. |
| 24 |
|
| 25 |
Now my greatest practical concern: bugfix releases |
| 26 |
3) Sometimes Gentoo takes a long time to stabilize a bugfix release like |
| 27 |
media-gfx/gimp-2.6.6 (the latest arch-blessed release is 2.6.4); this |
| 28 |
release fixes many bugs and entered Portage in 2009-03-18 and by |
| 29 |
searching on b.g.o I can't find any regressions; and it entered Debian |
| 30 |
testing in 2009-04-01. I don't know the cause of this delay; I guess the |
| 31 |
arch testing teams are overworked. |
| 32 |
|
| 33 |
I often put these bugfix releases in package.keywords. Isn't it wise to |
| 34 |
use the latest bugfix release in a given major version? For example, I |
| 35 |
want to use sys-kernel/vanilla-sources-2.6.27.x, and since |
| 36 |
the last arch version is 2.6.27.12, far from the latest upstream stable |
| 37 |
version (2.6.27.24), I put |
| 38 |
=sys-kernel/vanilla-sources-2.6.27* |
| 39 |
in |
| 40 |
/etc/portage/package.keywords/shortterm. |
| 41 |
|
| 42 |
When I see a new bugfix release of a package I care about, I look at the |
| 43 |
changelog to see the bug corrections. I decide how much to wait before |
| 44 |
putting the bugfix version in package.keywords depending on the severity |
| 45 |
of the fixed bugs (and I look at bugs.gentoo.org for any regressions, |
| 46 |
and I look if the version has been accepted in distros like Debian |
| 47 |
testing). For example, I put mail-client/claws-mail-3.7.1 in |
| 48 |
package.keywords nearly immediately due to the importance of the bug fixes. |
| 49 |
|
| 50 |
Is it wise to do this for any program? Maybe only for programs not part |
| 51 |
of the core base system (such as the toolchain, bash or coreutils*), |
| 52 |
relying on the developers for the base system? |
| 53 |
|
| 54 |
Or maybe I should just stick to all-stable, so as to not be different, |
| 55 |
and keep package.keywords for those packages where I really want a new |
| 56 |
feature (like packages with no stable versions)? |
| 57 |
|
| 58 |
* Speaking of coreutils, it is still at 7.1, with upstream having |
| 59 |
released 7.4, which fixes bugs in 7.1 . |
Archives