libspf2 (pulled in by opendmarc and exim) owns /usr/bin/spfd, while Mail-SPF (pulled in by spamassassin) owns /usr/sbin/spfd. Reproducible: Always Steps to Reproduce: 1. emerge exim (with spf support) and spamassassin 2. emerge merge-usr 3. merge-usr --dryrun Actual Results: # merge-usr --dryrun INFO: Migrating files from '/bin' to '/usr/bin' INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists INFO: No problems found for '/bin' INFO: Migrating files from '/sbin' to '/usr/bin' INFO: No problems found for '/sbin' INFO: Migrating files from '/usr/sbin' to '/usr/bin' ERROR: Conflict for file '/usr/sbin/spfd': [Errno 17] File exists: '/usr/bin/spfd' ERROR: Leaving '/usr/sbin' as a directory due to prior errors INFO: Migrating files from '/lib' to '/usr/lib' INFO: Skipping symlink '/lib/libcrypt.so.2'; '/usr/lib/libcrypt.so.2' already exists INFO: No problems found for '/lib' INFO: Migrating files from '/lib64' to '/usr/lib64' ERROR: Conflict for symlink '/lib64/libnsl.so': [Errno 17] File exists: '/usr/lib64/libnsl.so' INFO: Skipping symlink '/lib64/libcrypt.so.2'; '/usr/lib64/libcrypt.so.2' already exists ERROR: Leaving '/lib64' as a directory due to prior errors A similar problem happens with libnsl.so, where /lib64/libnsl.so is owned by glibc and /usr/lib64/libnsl.so is owned by net-libs/libnsl (pulled in by opensp and exim).
@Petr, given your change/fix in -r4, should we go for stable?
Yes, I think we should go stable with -r4, given it's the second similar report.
stabilization requested in bug 928284.
Mail-SPF/Mail-SPF-2.9.0-r4 is stable in ::gentoo and -r3 was dropped. Update to -r4 resolves this issue.
Thanks for the quick fix. FWIW, the "similar problem" mentioned in my original report was due to a stale symlink created way back in 2017.
