Tom Wijsman wrote: > 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 consider it stable when things work as they should except for known bugs upstream. Obviously if there is a known bug upstream then that bug will likely filter right on through to Gentoo. That said, if the Gentoo devs can correct a issue, they do so but that is not always the case either. > > > 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. It does require prior knowledge which is why I said what I did. I used to do emerge -u world way back when. That would SOMETIMES lead to issues because it may not go deep enough. Then I added -D which helped but from time to time would still miss something. So, I added the backtrack to make.conf. That improved things even more. Over time, I realized that I needed to add the -N option so it got added to the command. As it is now, I have that knowledge. I learned some of that the hard way. You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. Right now, that has lead me to the most stable OS. When it doesn't, I do a emerge -e world if nothing else fixes the issue. That doesn't happen as much as it used to because either Zac is tweaking portage or devs are doing better on the ebuilds. Heck, it could be both since both need to work well to get a good end result. > >> 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. * I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Obviously something fell through the cracks that my usual command would miss but the -e would catch since it does all packages. I never reported the issue since I don't know what specifically fixed the issue. There is no way for a person to figure out if it is a portage issue, ebuild issue or some other issue. I didn't see the point in filing a bug because there is no way to track down the source of the problem. This is my experience. By all means, if you do something different and it works for you, do it your way. I'm going to continue doing what works for me. If someone asks me how I do things, I'll recommend the same command/settings I use just like I'm sure some other old timers will do. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
