app-portage/unsymlink-lib-6 behaves very bad in unexpected situations: In my case, I had simply removed a while ago the empty directory /usr/lib/environment.d which belongs to systemd. Apparently, unsymlink-lib --analyze does not check whether the directory (which of course still was in /var/db) actually exists, and unsymlink-lib --migrate died with an error indicating that 1 copy operation had failed. After this, there was chaos: Neither unsymlink-lib --migrate nor unsymlink-lib --analyze not unsymlink-lib --rollback did work (because none of the states was properly reached). I could find a way out of the situation by understanding the python code and understanding what was actually intended and where the current state was stored, but IMHO this should not be necessary and clearly documented. Also I can imagine other reasons for the copy operation to fail (running out of disk space, some permission problems with SELinux etc.), so it would be nice if there would be an automatic way to recover from a failed copy somehow.
It is by design. The first and foremost goal of this tool is to avoid breaking the system. Therefore, it only proceeds if it can clearly recognize the system state. If the tool fails for some reason, you aren't supposed to bash the keyboard. You are supposed to analyze the problem, report a bug and recover manually using the instructions provided by the support. Even if you insist on solving the problem on your own without helping others that could run into it, 'unsymlink-lib --migrate' gives a pretty clear suggestion: .../lib.new exists! do you need to remove failed migration?
(In reply to Michał Górny from comment #1) > It is by design That the tool cannot proceed without manual intervention is OK. But it should inform the user clearly what it already did and what it had omitted in an error case so that the user has enough information to recover without reading the source code. > The first and foremost goal of this tool is to avoid breaking the system. Leaving the system in an (to the user) unknown state by not letting the user know what exactly was done to the system is almost the worst breakage which can happen. > gives a pretty clear suggestion > .../lib.new exists! do you need to remove failed migration? Yes, the user _might_ guess that creating lib.new was all that had happened. But instead of letting the user guess, it would be better to tell him. Not when he attempts to recover but actually before, namely in the moment when the error occurs. --migrate --pretend had printed a long list. But in the error case, the user has to guess where in the list the error occurred and/or whether something else from the list was done anyway. The user cannot even look at the list anymore if he had not saved it in advance.
...or he may actually read the README. But whatever, I've expanded error handling and added two 'forced' recovery actions.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a272f56304c3f81576ed346dfa3d49257284bc6c commit a272f56304c3f81576ed346dfa3d49257284bc6c Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2017-12-29 23:31:02 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2017-12-29 23:33:50 +0000 app-portage/unsymlink-lib: Bump to v8 Now with extra actions to help with recovery from fatal failures and detailed error messages with instructions how to recover. Closes: https://bugs.gentoo.org/642578 app-portage/unsymlink-lib/Manifest | 1 + app-portage/unsymlink-lib/unsymlink-lib-8.ebuild | 25 ++++++++++++++++++++++++ 2 files changed, 26 insertions(+)
> The bug has been closed via the following commit(s): Thanks! The messages are much clearer now. I think that this will help users a lot in an error case.
