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 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 ]
