From an IRC conversation: the epm -qf behavior isn't very good. it's easily fooled and it's not as good as rpm. it has this big ol' chunk of code that I don't like. # Trim trailing slashes from directories $a =~ s#/*$##; # If it's a relative pathname, then figure out the full pathname if ($a !~ m#^/# || $a =~ m#/\.\./#) { # Make the pathname absolute if ($a =~ s#/([^/]+)$##) { my $name = $1; $a = abs_path($a) . '/' . $name; } else { $a = abs_path('.') . '/' . $a; } } that whole thing could be replaced with: $a = abs_path($a) || $a; but that's not good enough because it's still not as good as rpm. rpm is much better at "abs_path" than epm is. oh, and btw, the || $a bit is because if abs_path can't deal with what you passed in, it passes back undef. and that's really the case I'm focusing on because it annoys me the most: when a file is gone, epm might not be able to tell you which package used to own it. rpm works really well in this case: rpm -qf ../../../usr/info/../info/cssc.info CSSC-0.11alpha.pl2-1
Suggestion: Could the summary of this bug be, "app-portage/epm unable to tell owner of missing file" or something more informative than its current summary?
Reassigning to maintainer-needed since package was not being maintained by anyone in tools-portage herd.
I don't get what exactly this bug is about. Getting relative paths, even for files that were gone, works perfectly: $ sudo mv -v /usr/share/man/man1/epm.1.bz2 /usr/share/man/man1/epm__.1.bz2 ‘/usr/share/man/man1/epm.1.bz2’ -> ‘/usr/share/man/man1/epm__.1.bz2’ $ epm -qf ../../../../usr/share/man/../man/man1/epm.1.bz2 epm-1.33
Created attachment 336576 [details, diff] patch Aron was probably right that only working with absolute paths is easier. Here's the patch he drew up in comment 0.
*** Bug 351554 has been marked as a duplicate of this bug. ***
This is fixed in app-portage/epm-1.40
