With the usr and bin and lib merges as so: $ ls -l /usr /sbin /lib lrwxrwxrwx 1 root root 5 Nov 25 03:30 /lib -> lib64/ lrwxrwxrwx 1 root root 3 Jun 25 2014 /sbin -> bin/ lrwxrwxrwx 1 root root 1 Apr 22 2015 /usr -> ./ The (relatively) new(er) python-based revdep-rebuild is (still) broken in 0.3.3: * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please file bugs at: https://bugs.gentoo.org/ * Collecting system binaries and libraries * Checking dynamic linking consistency * Assign files to packages !!! Broken orphaned files: No installed package was found for the following: * /bin/systemd-delta * /bin/systemd-sysusers * /bin/systemd-machine-id-setup * /bin/networkctl * /bin/systemd-cgls * /bin/timedatectl * /bin/systemd-socket-activate * /bin/systemd-notify * /bin/systemctl * /bin/systemd-firstboot * /bin/loginctl * /bin/systemd-resolve * /bin/systemd-cgtop * /bin/busctl * /bin/systemd-cat * /bin/systemd-tmpfiles * /bin/systemd-tty-ask-password-agent * /bin/localectl * /bin/coredumpctl * /bin/systemd-mount * /bin/systemd-inhibit * /bin/systemd-escape * /bin/bootctl * /bin/systemd-run * /bin/systemd-detect-virt * /bin/hostnamectl * /bin/systemd-ask-password * /bin/systemd-stdio-bridge * /bin/systemd-path * /bin/machinectl * /bin/systemd-analyze * /bin/journalctl * /bin/systemd-nspawn There is nothing to emerge. Exiting. Of course those binaries are not in the package database as /bin/*, but under /sbin/* or /usr/(s)bin/*. Taking the first one as an example: $ equery b systemd-delta * Searching for systemd-delta ... sys-apps/systemd-232 (/usr/bin/systemd-delta) sys-apps/systemd-232 (/usr/share/bash-completion/completions/systemd-delta) Meanwhile, the old(er) shell-script-based revdep-rebuild.sh doesn't mention the files and says everything is consistent... this time. * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. But when it the older shell-based version says there's a problem, it list the binaries multiple times, once for each of the symlinked paths, one of which will match the package database, so it rebuilds that, fixing the other paths in the process since it's actually the same binaries listed multiple times. A rebuild of systemd (which owns most or all of those but on the /usr path), followed by another revdep-rebuild run, produces the same output, so the newer python-based revdep-rebuild seems to be breaking here on systemd, specifically. Maybe it can't find some systemd library due to the same symlink based breakage? (I've long had the problem, but in older versions thought it was due to the noisy breakage that turned out to be cache only. Since that's fixed in 0.3.3 and I can run it now without /that/ problem, it can't be that, so it's time to report the remaining problem. Just hoping the fix doesn't make the newer version as slow as the old one. But even if it does, slow but working still beats fast but broken.) Thanks, Duncan
it sounds like the python version needs to use realpath to get the correct path to search for the owning pkg. I'll have a look when I get the chance.
(In reply to Brian Dolbec from comment #1) > it sounds like the python version needs to use realpath to get the correct > path to search for the owning pkg. You may have meant this but didn't actually specify it... AFAICT, the problem is that while the on-filesystem side may already use realpath (certainly the given path was the symlink-resolved canonical one, so unless that's just the first path it happened to check it appears it was already doing realpath), the package-database side doesn't, so the paths don't match. IOW, it seems to be the package-database side that's missing the realpath resolution, not the on-filesystem side. Thanks
(In reply to Duncan from comment #2) > (In reply to Brian Dolbec from comment #1) > > it sounds like the python version needs to use realpath to get the correct > > path to search for the owning pkg. > > You may have meant this but didn't actually specify it... > > AFAICT, the problem is that while the on-filesystem side may already use > realpath (certainly the given path was the symlink-resolved canonical one, > so unless that's just the first path it happened to check it appears it was > already doing realpath), the package-database side doesn't, so the paths > don't match. IOW, it seems to be the package-database side that's missing > the realpath resolution, not the on-filesystem side. > > Thanks That is the issue, it is the mismatch between the path of the binary and the path recorded in the package database.
This seems to be fixed as of gentoolkit-0.4.0. Thanks. =:^)
I spoke too soon. Reopening. 0.4.0 no longer lists the problem files so I'm only guessing it's the same problem, but always wants to rebuild systemd, even after I just rebuilt it. At least 0.4.0 can actually trace the files to systemd now. Previously it listed them as orphans and said nothing to rebuild. And both the detection and systemd rebuild are fast enough that it's still faster than using the old *.sh version, so at least I can use it now, even if it /is/ always rebuilding systemd (and /only/ systemd). =:^)
