Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Fri, 2022-07-29 at 01:17 +0200, Chris Hofstaedtler wrote: > * Ben Hutchings : > [..] > > Right. So this seems like a botched transition - fuse3 should have > > taken over the fuse binary package but instead each reverse-dependency > > has to be updated. I agree it would make sense in the short term to > > force fuse3 installation. > [..] > > Thank you for pointing out the problem. Even if the exact issue > > doesn't occur in Debian, we should sort out fuse vs fuse3. > > I would imagine #918984 is related. Right. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
* Ben Hutchings : [..] > Right. So this seems like a botched transition - fuse3 should have > taken over the fuse binary package but instead each reverse-dependency > has to be updated. I agree it would make sense in the short term to > force fuse3 installation. [..] > Thank you for pointing out the problem. Even if the exact issue > doesn't occur in Debian, we should sort out fuse vs fuse3. I would imagine #918984 is related. Chris
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Wed, 2022-07-27 at 14:25 +0200, Arnaud Rebillout wrote: > On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings > wrote: > > > > You should find out why that is, before proposing to override it. What > > if something in KDE really does need FUSE 2? > > I don't think that it can happen. A package might need FUSE3 (in such > case it depends on fuse3), or it might need FUSE (any implementation) > (in such case it depends on fuse, and it's either fuse or fuse3 that > will be installed, as fuse3 Provides fuse). But it cannot really ask for > FUSE2, as far as I understand (there's no fuse2 package). That makes sense. > In the case I described above, if fuse gets installed, it's not because > a package needs FUSE2, it's because no package needs FUSE3. So apt picks > fuse rather than fuse3. > Right. So this seems like a botched transition - fuse3 should have taken over the fuse binary package but instead each reverse-dependency has to be updated. I agree it would make sense in the short term to force fuse3 installation. > > (Since you found that removing fuse doesn't remove anything else, this > > implies that the relationship is only a Recommends and not a Depends. > > But that doesn't mean that removal won't break anything.) > > I believe that if replacing fuse by fuse3 doesn't remove anything, it's > because fuse3 Provides fuse. > > In any case: in Kali we solved that by recommending fuse3 in > kali-desktop-core, a metapackage that is always installed with every > Kali desktop. Therefore we're sure to have fuse3 (we don't let apt > guess), and we're sure that open-vm-tools will be installed if needed. > It's a better solution than modifying hw-detect as I suggested here. > > Therefore I'll close this bug, as I don't think it affects Debian anyway. > > Thanks for your feedback, and sorry for the noise. Thank you for pointing out the problem. Even if the exact issue doesn't occur in Debian, we should sort out fuse vs fuse3. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings wrote: > > You should find out why that is, before proposing to override it. What > if something in KDE really does need FUSE 2? I don't think that it can happen. A package might need FUSE3 (in such case it depends on fuse3), or it might need FUSE (any implementation) (in such case it depends on fuse, and it's either fuse or fuse3 that will be installed, as fuse3 Provides fuse). But it cannot really ask for FUSE2, as far as I understand (there's no fuse2 package). In the case I described above, if fuse gets installed, it's not because a package needs FUSE2, it's because no package needs FUSE3. So apt picks fuse rather than fuse3. > (Since you found that removing fuse doesn't remove anything else, this > implies that the relationship is only a Recommends and not a Depends. > But that doesn't mean that removal won't break anything.) I believe that if replacing fuse by fuse3 doesn't remove anything, it's because fuse3 Provides fuse. In any case: in Kali we solved that by recommending fuse3 in kali-desktop-core, a metapackage that is always installed with every Kali desktop. Therefore we're sure to have fuse3 (we don't let apt guess), and we're sure that open-vm-tools will be installed if needed. It's a better solution than modifying hw-detect as I suggested here. Therefore I'll close this bug, as I don't think it affects Debian anyway. Thanks for your feedback, and sorry for the noise. Arnaud
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Thu, 2022-07-14 at 16:56 +0200, Arnaud Rebillout wrote: > Source: hw-detect > Version: 1.147 > Severity: normal > User: de...@kali.org > Usertags: origin-kali > > Dear Maintainer, > > The package open-vm-tools 11.3.5, released in January 2022, depends on > fuse3 rather than fuse [1]. > > As a consequence, hw-detect fails to install open-vm-tools if ever the > package fuse was already installed. This is because installing fuse3 > would cause the removal of fuse, and removals are not allowed. > > This can be seen in the logs of the installer: > > in-target: The following additional packages will be installed: > in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3 > in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5 > in-target: libsigc++-2.0-0v5 open-vm-tools zerofree > in-target: Suggested packages: > in-target: cloud-init > in-target: The following packages will be REMOVED: > in-target: fuse > in-target: The following NEW packages will be installed: > in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3 > in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5 > in-target: libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree > in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded. > in-target: E: Packages need to be removed but remove is disabled. > > In practice, it hits Kali Linux users, as reported in [2]. For some > reasons, fuse gets installed if users install the KDE desktop for Kali. [...] You should find out why that is, before proposing to override it. What if something in KDE really does need FUSE 2? (Since you found that removing fuse doesn't remove anything else, this implies that the relationship is only a Recommends and not a Depends. But that doesn't mean that removal won't break anything.) If we find that it's not really needed, then a better fix may be to remove the recommendation(s) or change them to "fuse3 | fuse". Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
Source: hw-detect
Version: 1.147
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Dear Maintainer,
The package open-vm-tools 11.3.5, released in January 2022, depends on
fuse3 rather than fuse [1].
As a consequence, hw-detect fails to install open-vm-tools if ever the
package fuse was already installed. This is because installing fuse3
would cause the removal of fuse, and removals are not allowed.
This can be seen in the logs of the installer:
in-target: The following additional packages will be installed:
in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target: libsigc++-2.0-0v5 open-vm-tools zerofree
in-target: Suggested packages:
in-target: cloud-init
in-target: The following packages will be REMOVED:
in-target: fuse
in-target: The following NEW packages will be installed:
in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target: libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree
in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
in-target: E: Packages need to be removed but remove is disabled.
In practice, it hits Kali Linux users, as reported in [2]. For some
reasons, fuse gets installed if users install the KDE desktop for Kali.
Does it happen in Debian as well? A quick check tells me that it does
NOT happen for GNOME, as gnome-core Depends on gvfs-fuse which Depends
on fuse3. But for other desktop environments I don't know.
I've seen that the script apt-install supports an option --allow-remove,
so I wonder if we could make use of it in this case, to make installing
open-vm-tools more reliable.
For example, this kind of patch:
diff --git a/hw-detect.finish-install.d/08hw-detect
b/hw-detect.finish-install.d/08hw-detect
index a91bff07..5269f114 100755
--- a/hw-detect.finish-install.d/08hw-detect
+++ b/hw-detect.finish-install.d/08hw-detect
@@ -103,10 +103,12 @@ enable_modules_loading() {
case "$(detect_virt)" in
vmware)
+ # open-vm-tools depends on fuse3, which Replaces fuse,
+ # so we allow removal in case fuse is already installed.
if detect_desktop; then
- apt-install --with-recommends open-vm-tools-desktop || true
+ apt-install --with-recommends --allow-remove open-vm-tools-desktop
|| true
else
- apt-install --with-recommends open-vm-tools || true
+ apt-install --with-recommends --allow-remove open-vm-tools || true
fi
;;
oracle)
Does anyone has an opinion on that? I can submit a patch if you think
it's a good idea.
Cheers,
Arnaud
NB: fuse3 seems to be a drop-in replacement for fuse:
Package: fuse3
Version: 3.11.0-1
[...]
Provides: fuse (= 3.11.0-1)
Depends: libc6 (>= 2.33), libfuse3-3 (= 3.11.0-1), adduser,
mount (>= 2.19.1), sed (>= 4), lsb-base (>= 3.2-14)
Breaks: fuse
Replaces: fuse
References:
[1]:
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/d5176b54
[2]: https://bugs.kali.org/view.php?id=7774
