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