libcrypt file collision. [SOLVED ?]

[dmpogo]

Yes, I know some variations of the problem have been discussed, but I am still not sure what I should do

On the today world update, I got a some list of rebuilds due to the change to libcrypt, which started with glibc

After glibc was emerged, sys-libs/libxcrypt-4.4.25::gentoo refuses to install with file collisions

Code: Select all

Detected file collision(s):
 * 
 *      /usr/include/crypt.h
 *      /lib64/libcrypt.so.1
 * 
 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * sys-libs/glibc-2.33-r7:2.2::gentoo
 *      /lib64/libcrypt.so.1

where indeed I have /lib64/libcrypt.so.1 belonging to glibc that was just installed.
I do have root window, and generally root access, so am in better shape that other posters.
But what is the procedure to get out of this block ?

[dmpogo]

OK, it is resolved with

FEATURES='-protect-owned' emerge --oneshot libxcrypt

as is mentioned in bug #802207.

Strangely, this is needed not on all my machines, laptop with protect-owned enabled (which is a profile default) did upgrade successfully without any trickery.

[mmogilvi]

I also got a file collision and needed to do the equivalent of
FEATURES='-protect-owned' emerge --oneshot libxcrypt
on the first machine I updated, but 5 or 6 other machines worked fine without it. The suggested FEATURES="-collision-protect unmerge-orphans" from the news item did not work; those are already the default. (One machine was unclear: I was anticipating problems and trying to split the update into multiple commands so that one of the commands could be the "-protect-owned" with only the one package, but I didn't notice if it was actually required.)

Various forum and bug comments seems to suggest that this state can happen occasionally, but not often. Nobody seems to have any idea why it happens. Speculation: I wonder if there was some early temporary incomplete update/bug in the portage tree somewhere that was fixed a little while later, since although it mostly isn't stated explicitly, it seems like it may be most common with "first" machine people update? But looking at file timestamps and git history online (in relevant package and eclass directories) doesn't reveal any obvious related changes.

Suggestion 1: Do not try to fix such a collision by re-emerging glibc a second time prior to getting libxcrypt installed. I didn't try it, but if I read the ebuild correctly and various forum comments/etc correctly, it won't preserve libcrypt.so.1 the second time, which will break perl and prevent libxcrypt from installing until you somehow replace libcrypt.so.1 manually. (Perhaps it would be more robust if the glibc ebuild always attempted to preserve an existing libcrypt.so.1 if "sys-libs/libxcrypt" is not yet installed, instead of only looking at the previously-merged glibc[crypt] use flag? Is that possible?)

Suggestion 2: Perhaps it would be advisable to make your own copy of /lib64/libcrypt.so.1, prior to trying to update (or at least before trying to recover after a failed update). Otherwise, if you lose that file, you may have to copy from another machine and/or a fresh stage3 to recover. Also watch out for actual file content vs symlink...

Suggestion 3: Be careful to leave a root shell logged in until everything checks out correctly. Use another window to confirm ability to login and become root, etc.

[dmpogo]

Yes, in my case 2 out of 3 machines had no problems, but one failed to install libxcrypt