Hello Guillem, and thanks for your bugreport,
Le samedi, 29 février 2020, 00.39:56 h CET Guillem Jover a écrit :
> This package is making incorrect use of dpkg-statoverride for a
> volatile pathname under /run that is not managed by dpkg.
This code predates my time and is in hplip since at least 2005. But now is a
good time to fix it.
> In addition the recent migration from /var/run to /run does not include
> cleanup of /var/run.
My understanding is that as /var/run is a symlink to /run, there's no cleanup
to be done. Or are you talking about cleaning up the dpkg-statoverride's
database? In that case, both the /var/run/hplip _and_ the /run/hplip entries
now would need to be removed from that database, right?
> statoverrides are intended to be used on pathnames shipped by a
> package that dpkg will unpack, otherwise this will have no effect if
> the path did not exist at --update time. While there are plans to
> add support for volatile/ghost files to dpkg, this is not the case
> right now, so you need to manage this in some other way for /run,
> and cleanup the statoverride for /run and /var/run to avoid leaving
> cruft behind.
This seems to confirm my understanding from above.
I have checked the hplip code and it seems that the rundir is not in use at
all, so just removing this code (and the statoverride entries) should just
work.
So would this be an appropriate patch?
--- a/debian/hplip.postinst
+++ b/debian/hplip.postinst
@@ -20,10 +20,11 @@ case "$1" in
exit 1
}
- for i in /run/hplip
+ # Statoverrides in ephemeral directories don't work. They should be
removed (#952580)
+ for i in /run/hplip /var/run/hplip
do
if ! dpkg-statoverride --list $i > /dev/null; then
- dpkg-statoverride --update --add hplip root 755 $i
+ dpkg-statoverride --remove $i
fi
done
Thanks for your input!
Cheers,
OdyX
