Le 9/04/19 à 18:58, Arturo Borrero Gonzalez a écrit :
On 4/9/19 6:34 PM, Laurent Bigonville wrote:
Package: ebtables
Version: 2.0.10.4+snapshot20181205-2
Severity: serious
Hello,
On system with usr-merge, removing ebtables breaks the alternative.
The postinst script install symlinks from /sbin to /usr/sbin, in the
prerm script these symlinks are removed. BUT ebtables also add itself as
an alternative for ebtables implementations.
That means that the symlinks installed by update-alternatives are
rm when the package is removed.
Not too sure how to fix this, maybe the prerm script should check if the
symlinks directly point to a real file and only remove them in that
case?
Thanks for the report!
I don't use usr-merge, so it would be great if you can provide concrete examples
of which files and which symlinks are affected by the bug you are describing,
and what would be the right state after package removal for them.
On a usr-merge system, /sbin is a symlink pointing to /usr/sbin. The
alternative symlinks are installed in (/usr)/sbin.
In the postinst you have:
# compat symlinks for /sbin -> /usr/sbin move, to be dropped in buster+1
LIST="/sbin/ebtables /sbin/ebtables-save /sbin/ebtables-restore"
for i in $LIST ; do
if [ ! -e "$i" ] ; then
ln -sf /usr$i $i
fi
done
On a usr-merge system, this will rightfully do nothing as
/sbin/ebtables* are already existing, so that's OK
OTOH, in the prerm you have:
LIST="ebtables ebtables-save ebtables-restore"
for i in $LIST ; do
if [ -L "/sbin/$i" ] ; then
rm /sbin/$i
fi
done
On a non-usr-merge system, the symlinks in /sbin and the symlinks (from
the alternative system) in /usr/sbin are different. On a usr-merge
system, they are not. That means that you end up removing the symlinks
from the alternative system and not the one you have (supposedly) created.
AFAICS, this also impacts arptables package.
Note that usr-merge is now the default on all new debian installation.
