1 |
Philip Webb posted <20060505073706.GB6335@×××××××××.ca>, excerpted below, |
2 |
on Fri, 05 May 2006 03:37:06 -0400: |
3 |
|
4 |
> That's very much my own impression. I am now using ~x86 versions of Vim |
5 |
> Vim-core Gvim Cdargs Openoffice Eix Euses Gqview Gwenview Portage Firefox |
6 |
> Galeon Htop KDE -- all of which which I use regularly -- & Abiword |
7 |
> Gnumeric Koffice Gnugo Qgo Qalculate-kde (which I rarely use). I have had |
8 |
> no problem with any of them. |
9 |
> |
10 |
> My solution is a line in .bashrc : |
11 |
> 'alias emergeu='ACCEPT_KEYWORDS="~x86" emerge' , |
12 |
> which allows me to emerge a testing version on a specific occasion. The |
13 |
> package.keywords alternative is silly, as there's no reason anyone would |
14 |
> want to do it regularly for a package, as opposed to occasionally when -- |
15 |
> increasingly -- stabilisation is late. |
16 |
> |
17 |
> I do a weekly 'eix-sync' & check the list of packages which have changed, |
18 |
> then decide which ones to update; I never do 'emerge world'. I keep an |
19 |
> upto-date file with a line for each package I have installed, incl date, |
20 |
> version & the main dependencies it satisfies (if any): this is my |
21 |
> alternative to 'world', which is clumsy & causes problems. |
22 |
> |
23 |
> I have been doing this since I started using Gentoo in Oct 2003 & have |
24 |
> never had any problem with Portage or packages as a result. |
25 |
|
26 |
Here, I simply use ~amd64 for my entire system, and rarely have problems. |
27 |
When I do, that's what those backup snapshot partitions I keep around are |
28 |
for. |
29 |
|
30 |
Gentoo is really fairly conservative with ~arch. That does /not/ mean the |
31 |
package is broken, or the upstream package is unstable. Rather, it means |
32 |
the upstream package is reasonably stable, and the Gentoo ebuild is known |
33 |
to work and is tested at least by the Gentoo maintainer. |
34 |
|
35 |
Really broken packages and packages known to have very serious issues on |
36 |
Gentoo aren't ~arch at all, but are instead hard-masked, either with the |
37 |
-* keyword, or with an entry in package.mask. |
38 |
|
39 |
Given these facts, I'm of the opinion that most of those running stable |
40 |
that are calling for faster package stabilization, should really be |
41 |
running ~arch. That's doubly true for those finding they have an |
42 |
ever-growing package.keywords and/or those calling for a "middle" keyword. |
43 |
In point of fact, ~arch /is/ that middle keyword, because the really |
44 |
unstable packages are hard-masked and not in ~arch in the first place. |
45 |
|
46 |
Actually, I run selected hard-masked packages as well. Particularly with |
47 |
things like gcc, which is slotted and easily managed with gcc-config or |
48 |
eselect compiler, it's quite easy to run hard-masked stuff in parallel. |
49 |
Something like xorg isn't as easy to run in parallel as it's not slotted, |
50 |
but even there, given FEATURES=buildpkg, if one has the time and |
51 |
motivation to test a masked version, it's relatively painless to revert |
52 |
to an old version if the test doesn't work out so well (with the caveat of |
53 |
course that one keeps backups, as one should anyway, in case something |
54 |
goes /really/ wrong -- it IS hard-masked packages we are talking about |
55 |
now, after all). |
56 |
|
57 |
Again, I don't see the problem. Stable is there for those that want it. |
58 |
~arch is there for those that want something newer, with a bit of extra |
59 |
risk. Hard-masked-for-testing packages are very often there for those who |
60 |
REALLY want bleeding edge -- along with the associated increase in risk. |
61 |
If folks don't like how far behind stable is, and are willing to risk not |
62 |
only their own systems with the package in its current state, but the |
63 |
systems of everyone else running stable (which is what requesting faster |
64 |
stabilization actually comes down to), they shouldn't be running stable |
65 |
after all, but the "middle" keyword, that being ~arch. That way, they get |
66 |
their newer, mostly stable programs, while everyone who /really/ wants |
67 |
stable doesn't end up with the risk of stabilizing the package too fast. |
68 |
Of course, note that package.keywords works both ways. Folks running |
69 |
~arch as their regular keyword can set specific packages to arch (stable) |
70 |
in package.keywords too. Again, Gentoo is very flexible in that regard -- |
71 |
some might say insanely flexible, but it works, if people would only read |
72 |
the docs and follow them as appropriate. |
73 |
|
74 |
-- |
75 |
Duncan - List replies preferred. No HTML msgs. |
76 |
"Every nonfree program has a lord, a master -- |
77 |
and if you use the program, he is your master." Richard Stallman in |
78 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
79 |
|
80 |
|
81 |
-- |
82 |
gentoo-dev@g.o mailing list |