| 1 |
On 12/23/2009 11:36 PM, Duncan wrote: |
| 2 |
> ~arch does mean more and faster updates and that you should be prepared |
| 3 |
> to resort to an alternate boot image, live/rescuecd or the like, in |
| 4 |
> ordered to fix things if necessary, but that's a good idea in any case. |
| 5 |
> And at least a package is normally tested to work on the developer's |
| 6 |
> ~arch system before it's keyworded ~arch, even if it's not tested to the |
| 7 |
> degree that stable is. But a half-stable half-~arch system is a no-man's- |
| 8 |
> land, really not tested, nor practically testable since there's so many |
| 9 |
> possible variants, at all. So if you're running more than a very limited |
| 10 |
> set of ~arch packages (with few dependencies), I'd definitely recommend |
| 11 |
> ~arch over stable with many ~arch packages. At least that's known to |
| 12 |
> work on the dev's full ~arch system, something that cannot be said of a |
| 13 |
> half-way ~arch installation. |
| 14 |
|
| 15 |
But the only way to be sure that an ~arch plays nicely with the |
| 16 |
currently stable packages is to *not* go full ~arch. With full ~arch, |
| 17 |
you only knows that the package plays well with the latest version of |
| 18 |
all packages; but you don't know how it performs with the stable tree. |
Archives