The 'qfile' utility of package 'app-portage/portage-utils' currently does not distinguish between 'has no owner' and 'error'/'invalid', e.g. $ qfile /tmp; echo $? -> 1 (/tmp exists but is not owned by any package) $ qfile /tmp/notthere; echo $? -> 1 (/tmp/notthere does not exist) For scripting, it would be desirable for 'qfile' to return different codes, e.g. 0 == has owner, 1 == has no owner, 2..n == error occurred (file/folder does not exist, failed to query database, ...whatever...).
This shouldn't conflict with this request but, on a side-note, iwdevtools-0.10.0 currently relies on the following: $ qfile /lib/libsame.so /usr/lib/libsame.so +..more libs in a single call Only one libsame.so exist in VDB, but script expect that to return 0 and ignore the other one. Does expect an error if /all/ paths returned nothing, but doesn't care if it'll return 1 or 2 to indicate something different. (it's a workaround for usr-merge systems that annoyingly don't always have the right paths recorded in VDB, so it's a guessing game -- full paths are used to avoid picking up /opt/something/bundled/libsame.so) Just mentioning given I'd like to know ahead of time if that will break, if possible I'd rather not have to do multiple qfile calls though.
qfile is a query tool to search the database in /var/db/pkg. I do not think qfile should care about the status of the file in the live file system. If the file exists in /var/db/pkg/*/*/CONTENTS, qfile outputs the path and exits with status 0. If the file does not exist in /var/db/pkg/*/*/CONTENTS, qfile exits with status 1. For scripting, you probably want to do something like this: test -e /tmp/notthere && qfile /tmp/notthere
(In reply to Mike Gilbert from comment #2) > qfile is a query tool to search the database in /var/db/pkg. > > If the file exists in /var/db/pkg/*/*/CONTENTS, qfile outputs the path and > exits with status 0. > > If the file does not exist in /var/db/pkg/*/*/CONTENTS, qfile exits with > status 1. That's what thought, thanks for confirming. > For scripting, you probably want to do something like this: > > test -e /tmp/notthere && qfile /tmp/notthere That's only part of a solution - if qfile returns 1, did it fail in its task or did it just not find any owner? That's an important difference.
(In reply to Maxxim from comment #3) > > test -e /tmp/notthere && qfile /tmp/notthere > > That's only part of a solution - if qfile returns 1, did it fail in its task > or did it just not find any owner? That's an important difference. Hmmm This is a bit questionable (on qfile's end) but there isn't really such thing as failure. A CONTENTS file could be absent, qfile treats it as just a package without any deliverables (virtual?). CONTENTS file corrupt? qfile cannot know, and will just not match anything (or something random). qfile warns a bit here and there when it gets a bit confused when it cannot read symlinks etc, but it won't fail on that, it will just continue with what it has.
I'm not sure if this is something you're looking for, but if you just want to know if a file is owned by a package you can use the orphan feature, e.g.: % qfile -o /bin/nosh /bin/bash /bin/dash /bin/sh /bin/nosh /bin/sh (on my system, indicating that /bin/nosh and /bin/sh are not owned by any package).
(In reply to Fabian Groffen from comment #4) > This is a bit questionable (on qfile's end) but there isn't really such > thing as failure. A CONTENTS file could be absent, qfile treats it as just > a package without any deliverables (virtual?). CONTENTS file corrupt? > qfile cannot know, and will just not match anything (or something random). > qfile warns a bit here and there when it gets a bit confused when it cannot > read symlinks etc, but it won't fail on that, it will just continue with > what it has. Missing CONTENTS file, insufficient permissions to access /var/db/pkg, I/O error while reading... there are probably countless ways something could go wrong. Of course, one wouldn't expect things to go wrong, but as developers we all know that one may hope for, but shouldn't rely on things going smoothly. (In reply to Fabian Groffen from comment #5) > I'm not sure if this is something you're looking for, but if you just want > to know if a file is owned by a package you can use the orphan feature, e.g.: > > % qfile -o /bin/nosh /bin/bash /bin/dash /bin/sh > /bin/nosh > /bin/sh > > (on my system, indicating that /bin/nosh and /bin/sh are not owned by any > package). In my specific case, I'm trying to find the owner for a certain path. If a package is found, it is uninstalled. If no package is owning the path, a warning is issued. If determining the owner fails, the script is supposed to bail out and ask for user intervention. The 'bailling out' path is currently blocked due to qfile's behavior.
