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


Reply via email to