xbps-install -u xbps may leave system in an unusable state

[oreo639]

When updating through xbps, if the repositories have an update for xbps available, then the only install/update action that may be performed is xbps-install -u xbps.

Since this may sometimes result in a situation where xbps may be unable to be updated since one of its dependencies may break their dependents, the decision was made to have xbps-install -u xbps ignore all missing dependency and missing shlibs errors:
https://github.com/void-linux/xbps/blob/master/lib/transaction_ops.c#L276-L285

This is problematic since with glibc 2.38, libcrypt.so.1 was dropped. In order to upgrade xbps, glibc must be updated, however, the glibc upgrade may break glibc dependents, which gets ignored.

The comment in the transaction_ops.c file suggests that you can just make sure to do xbps-install -Su afterwards and the problem will be resolved, however, if something like PAM gets broken, then now you now are going to have a real hard time logging in or changing user (sudo, for example, won't work anymore).

My question is, is this really the best way to handle this or is there a more intelligent way to handle xbps self upgrades.
(I know it is too late to fix this for the old ISOs but if we can fix this for the future, then that would be nice)

[rubyFeedback]

Yes, that is also confusing. In my case binutils-doc could not be installed, so the rest of it was not installed either (I wanted to install gcc; and in my case the problem was that my temp dir did not exist). I think the xbps installer makes too many wrong assumptions by default. Some components of the linux stack require more care though as they can render the system unusable.