On Mon, 04 Nov 2013 06:06:52 -0600 Dale <rdalek1...@gmail.com> wrote:
> But after a person has used Gentoo a while, they figure out what > process leads to the most stable update process. Do they? What do you consider a stable update process? I come across users on a daily basis which - haven't upgraded their system lately because they're not good at it; - get into unclear slot conflicts locking them out of updates; - some build failure disallows their dependency graph from completing; - managed to finally update, but don't know about depclean; - managed to finally depclean, but don't know about eclean. It involves a lot of prior knowledge, manual checking and what in order to be able to update the system; I wouldn't label this "stable", but rather "dependent on the person updating it" and to some extent even "dependent on whether the person memorized all the docs and/or gets helped or get it told in the support channels". There are some improvements possible in these situations; I'm planning to discuss some ideas and write some patches where possible, and I hope other people jump on the bandwagon to help improve user experience. That doesn't mean I consider it bad or that we need to go hand holding. > The only way to get a more stable system is to do a emerge -e world > and update that way. At least that has been my experience so far. I have never needed this; I wonder whether there exists an example case for this, I only see this used when someone changes compiler / flags and wants to ensure the whole system turns into rice. * > If Zac adds some other nifty feature, then I may add to the above as > needed. For the past few years, that has resulted in as stable a > system as I can get. I do from time to time run emerge -e world just > for giggles when I have something acting odd and can't put my finger > on the issue. Sometimes, that fixes it, sometimes not. > > Again, most of this comes from experience. The handbook explains it > then the user figures it out from there. * http://funroll-loops.info/ -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
