On 23/07/2014 15:24, gottl...@nyu.edu wrote: > My normal updating procedure is > > EMERGE_DEFAULT_OPTS="--ask --deep --tree --verbose --jobs --load-average=5" > emerge --update --changed-use --keep-going @world > > I had mistakenly thought this would update all packages not at the > latest version (subject to package.accept_keywords, package.mask, ...). > > I now realize that it only does this for the packages in world and then > follows the dependency tree. So if package A in world is up to date, A > depends of B, and a new version of B appears, B will not be updated. > > As a result eix-test-obsolete finds that I have packages installed that > are no longer in the database. > > I could do > > emerge --update the-2-dozen-such-packages
emerge --depclean > > Is that wise? > > thanks, > allan > > PS This system is in the midst of the multi-month bothwick "goingstable" > procedure. I don't know if that is relevant to the decision. > > Neil Bothwick wrote: >> >> You can generate the list with >> >> qlist -ICv | sed -e 's/^/~/' -e 's/-r[1-9]$//' \ >> >/etc/portage/package.accept_keywords/goingstable >> >> This allows revision updates, which is useful as they usually contain bug >> or security fixes, but doesn't allow any higher versions. >> >> Occasionally running eix-test-obsolete will let you know which entries >> have become redundant because stable has caught up with them. >> >> I recently used it to move a machine from testing to stable. The one >> caveat is that sometimes the testing version your have installed, and in >> package.accept_keywords, is removed from the tree so portage wants to >> downgrade to the latest stable version. You have the choice of letting >> this happen or unmasking a later testing version. > > [ subsequently he recommended using the latter choice ] > > -- Alan McKinnon alan.mckin...@gmail.com