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.
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):
Author: Michał Górny <email@example.com>
AuthorDate: 2017-12-29 23:31:02 +0000
Commit: Michał Górny <firstname.lastname@example.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.
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.