Hi Eli,
> > warning: atop: /var/log/atop/dummy_after (Permissions mismatch)
> ...
> > Not every error means the file on disk must be changed, perhaps it's
> > a packaging problem
>
> pacman -S pacutils && paccheck --file-properties
Thanks.
$ sudo -i paccheck --file-properties atop
atop: '/var/log/atop/dummy_after' permission mismatch (expected 644)
atop: '/var/log/atop/dummy_after' modification time mismatch
(expected 2019-02-06 20:40:14)
atop: '/var/log/atop/dummy_before' permission mismatch
(expected 644)
atop: '/var/log/atop/dummy_before' modification time mismatch
(expected 2019-02-06 20:40:14)
$
The modification-time mismatch above suggests the package's mtree needs
to allow for the mtime to vary.
As an installation ages, it seems the number of disagreements between it
and the packages grows. What can be done to try and centrally fix some
of them for all installations?
I expect sometimes a package or upstream changed a file's properties in
the packaging, but neglected to alter what was already in place on the
upgrade to that package version. I'd have thought if research shows it
is the package, or upstream, that changed the properties then it's not
too late and the package can change to check and fix those on upgrade.
Do the packaging tools provide a means of checking that the proposed
mtree differs for existing items to the previous one? That would help
packagers realise upstream have made a change.
Blindly altering the filesystem to match mtree might be the wrong thing,
disguising a real problem. By getting rid of the noise caused by
package upgrades, real faults can start to be seen.
(BTW, can you quote just what's needed, following the Code of Conduct.)
--
Cheers, Ralph.
