Summary: | app-portage/gentoolkit-0.3.3 revdep-rebuild breaks with usr and bin merges | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Duncan <1i5t5.duncan> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duncan
2017-01-19 23:37:35 UTC
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). =:^) |