sb-md5 hasn't been modified in years, but it depends on sb-rotate-byte which was just tweaked because of :if-component-dep-fails. ASDF used to not propagate timestamps from system to system, or from .asd file to the system internals, but now it does both, and so the change in sb-rotate-byte.asd now causes sb-md5 to be out of date.
stassats tells me SBCL usually does a clean.sh as the first thing in make.sh, so if you built with make.sh instead of slam.sh, and didn't update your source in between make.sh and install.sh, there should be not have been an issue.
I suppose my position is: * if the bug is just due to unclean builds of SBCL, I'm not willing to fix, just rebuild SBCL from clean and reinstall. * if the bug is due to some deeper incompatibility that will affect people using binary distributions built from clean, or with the SBCL installation itself having been unclean, I shall write a fix or workaround (but then we should also fix these distributions or SBCL to be cleaner). But is that the case?
The only solution I understand so far is to run SBCL as root and rebuild the contribs, or modify the system directory permissions so a user can rebuild the contribs. That seems like a hassle, and I'd prefer not to do it, especially since I have a lot of SBCL installations around. It's also unlike anything else I normally do to fix CL problems.
Are there changes to SBCL that could be made to mitigate the problem? "Update SBCL and reinstall" is something I'm quite familiar with doing.
Update and reinstall from clean should do it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If all values are relative, then cannibalism is a matter of taste. — Leo Strauss