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 . |