Reliable way to determine package which own/update a file

[jonathan183]

I'm struggling to determine the packages which own or update files.
An example of a file which has no owner identified using equery is /lib/cpp I think it's owned by either gcc or gcc-config but it's not listed a file in either package (reported by equery).
I have tried comparing modify and change times report by stat with emerge log with date/times which match part way through emerge of gcc.

I also have files which are owned by a package for example /usr/share/vim/vim73/docs/tags which is owned by app-editors/vim-core-7.3.762 which has an md5sum which does not match.

I'm trying to confirm files are correct before updating the tripwire database.

I have tried grep -r 'lib/cpp' /usr/portage which pulls up a few matches in Changelog information.

Can anyone give me a clue of a better way of identifying packages which modify files, I don't want to have to resort to running something like tripwire after every package ... but the detective work of trying to work out whats modifying particular files is also time consuming.

[Anon-E-moose]

Not sure why that doesn't show up, but cpp is part of gcc.

It doesn't even show up when you do an "equery f gcc" not sure why, it has the same timestamp as the time gcc was emerged.

Something wrong with either portage or the gcc ebuild.

[krinn]

You'll only see files that are part of a package, any file not part of it won't show up.
so, user create configuration file, or for /lib/cpp a file create by the package itself, but not in the package list.

[Hu]

That file is unowned because it is a copy of the installed gcc-config helper binary. This could have been done as a symlink to the helper, which would be a bit clearer.

[jonathan183]

Thanks for the responses, so far it looks as though I'm going to be stuck with either a re-run of tripwire after every package update or a Columbo job on tracking down which package did the update ... are there really no more reliable/convenient methods of doing this?

[Hu]

For files not managed by the package manager, there is no general way to automatically verify them. For most files, they ought to be under package manager control. The ones you cited are not, for various reasons.

[Anon-E-moose]

/usr/bin/cpp and /lib/cpp are the same and should keep the same timestamp and md5 (or whatever) sig
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[jonathan183]

I can understand things which I generate or I have to take action after the package manager has finished ... things like the kernel and grub, but I was hoping something would be keeping track of things installed by packages - whether it's a copy of another file or not. There are also about 80 symbolic links in /usr/bin or /bin get reported as no package owner things like /usr/bin/vi linked to vim.

[cboldt]

/lib/cpp is installed by gcc-config. As reported above, it is a copy of /usr/bin/cpp. The copy is created by a script at ...

/usr/portage/sys-devel/gcc-config/files/gcc-config-*

As for finding all the files that are installed "without a trace," good question! gcruft.pl is designed to pick up files that aren't listed in the /var/db/pkg tree (which is another good place to run `grep -r [targetfile] /var/db/pkg/*). gcruft.pl uses the string "$libmap", which is plain old "lib" on my system. /$libmap/cpp is listed as an expected unaccounted file, in /usr/share/gcruft/exceptions/sys-devel/gcc-config.pl

Even with its built in list of exceptions (files expected to be unaccounted by portage), gcruft.pl threw up a list of some 250 files (not counting all the expected files in /usr/src and /lib/modules) that were not installed by a package, but do belong on my system.

How did you find the /usr/share/vim/vim73/doc/tags md5 mismatch? I would wonder if that file is one that undergoes changes in some routine fashion (i.e., just use of vim), or if the vim-base documentation package and help file navigation might be modified by some vim-plugin package.

[cboldt]

Based on use of gcruft.pl (and before that, findcruft), I know that there is a substantial number of expected unaccounted files in a typical Gentoo installation, beyond the files that you know you are creating after a package is installed. One can find how those files came to be, that's easy enough, albeit time consuming. Given the allowed flexibility in ebuild->patch->install, I don't think Gentoo is designed so that all automatically installed files and links even can be accounted for in the /var/db/pkg tree

If you thought all the installed files were accounted for, now you know the facts are otherwise.

[khayyam]

[jonathan183]

[cboldt]

Just tinkering around with your script snippets, and will share some ways to speed things up. Rather than start with the tripwire database to find out installed packages, this integrity check first finds all the installed packages by view of /var/db/pkg ...

[khayyam]

[steveL]

[cboldt]

Good tip on use of eix to get a list of all installed packages. It's fast too, only about a half second longer compared with the`ls | cut` combination. On the eix command, `eix -I#` is enough, the -c switch isn't needed when the -# (--only-names) switch is used.

I think my concatentation of all the package-installed files into all-package-files.txt is unnecessary, too. While `grep [string] /usr/portage/*/*/somefile` fails because the resulting argument is too long, `grep [string] /var/db/pkg/*/*/CONTENTS` works, at least it does on my systems.

I found it pretty easy to resolve the source of most of the mystery/orphan files, and the reason for the failed md5sum files too. Many are configuration changes, some are added configuration files, some files are added or changed by normal operation of the associated programs. I estimate the number of files that need additional inquiry (if one is determined to know where they came from) is 20-50.

Not that the study can be considered fully comprehensive. Using the methods discussed, the list of mystery/orphan files is limited by the tripwire policy file, which decides the files to be monitored by tripwire; and the list of md5sum errors is limited to the list of files in /var/db/pkg/*/*/CONTENTS. There are files outside of both of those sets, files in one list but not in the other, and files in both lists.

[khayyam]

[cboldt]

`find -exec {} +` is a great tool. The start of the script then would become:

[mv]

[mv]

[khayyam]

[cboldt]

I like the idea of putting the CONTENTS filenames into a variable, probably speeds things up a bit compared with building the list a few thousand times. No need to use `find` to build the array, this assignment works:

[jonathan183]

[cboldt]

[cboldt]

Useless use of cat alert! Dang.

grep "obj " /var/db/pkg/*/*/CONTENTS | wc