On Fri, Mar 30, 2012 at 08:13:55PM +0300, Peter Eisentraut wrote: > I appears to me, however, that what it's doing is effectively useless. > For example, I currently have this in the output of checkrestart -v: > > Process /usr/bin/dbus-daemon (PID: 1519) > List of deleted files in use: > /lib/i386-linux-gnu/libexpat.so.1.5.2 > > The (new) checkrestart -p determines that this file does not belong to > any package, so it ignores it. But the whole point is, it belonged to > a former package, which has been upgraded. So whenever a file is > renamed in a package upgrade, this approach breaks down. Note that with > shared libraries, the process has the file open that contains the minor > version. So pretty much every single library upgrade will be missed by > this.
You are right in that if the file is removed and a new file is installed
(with a new name) then checkrestart -p is largely useless as it is for these
situations. However, this will probably happen only when you are doing
upgrades in unstable (where libraries are frequently upgraded) but not in
stable (where library versions are not changed).
So the approach is still useful for those users running stable and doing
security upgrades which is one of the main goals of checkrestart.
For users running unstable, a way to fix this issue would be to check for
packages providing *newer* versions of the library, not just the old file
(which was deleted). For example, in your case, if the dpkg-query was
done like this:
dpkg-query --search "/lib/i386-linux-gnu/libexpat.so*"
instead of how it is currently done:
dpkg-query --search "/lib/i386-linux-gnu/libexpat.so.1.5.2"
The previous one can be useful to make checkrestart "known" that the former
library belongs to the
libexpat1 package, although it might lead to false positives if not coded
properly. Whileas the second one will not indicate any package (as the file
has been removed)
Does this sound like a viable approach?
Coding this into checkrestart might not be too difficult if we restrict
ourselves to only libraries (i.e. files under /lib and /usr/lib). I will try
to take a shot at this.
Regards
Javier
signature.asc
Description: Digital signature
