It is a real pity. Now that Whonix’s functionality is split into multiple packages, which made Whonix’s source code much simpler to grasp, we still cannot tell users who wish to remove certain functionality to simply uninstall the package. Each package still needs a mechanism to disable its functionality while being enabled.
We cannot simply tell users to remove it. Unfortunately, it’s not all that simple. There are side effects.
sudo apt-get purge uwt
They would see something like this.
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
anon-banned-packages anon-iceweasel-warning gpl-sources-download knetattach-hide power-savings-disable-in-vms poweroff-passwordless rads scurl shared-folder-help swap-file-creator swappiness-lowest tor-ctrl
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
anon-shared-packages-recommended* uwt* whonix-shared-packages-recommended*
0 upgraded, 0 newly installed, 3 to remove and 2 not upgraded.
After this operation, 152 kB disk space will be freed.
Do you want to continue [Y/n]?
Whonix inherits a limitation of Debian’s package management. (No idea if other distributions have a solution for this.) Unfortunately, there is no middle ground between Depends: and Recommends: that could be used for meta packages.
Documentation on how users could work around such issues has been added:
Also more verbose technical information on the issue:
Please check if these explanations make sense. I would be happy to clarify any questions you might have. Maybe you have an idea how to solve this mess, but I am not positive there is a solution here. Seems a limitation by Debian and it would require some kind middle ground between Depends: and Recommends: in debian/control.
I looked at how other packaging formats work and rpm seems to have a way to do what you need. I don’t know if Debian will accepts rpms. apt-rpm can install rpms on debian without conversion.
This is a weak reverse require. In Suse, the opposite of 1), does not exist in debian.
This is useful when the using recommends is not feasible or possible: A package can reasonably "recommend" its own sub-packages, but beyond that it might not be feasible or even possible at all: for example a packages from distro vendors cannot refer to every extension/enhancement package that may exist in 3rd party repositories at any given time. Or if you have a binary-only package which can't be modified, but when installed you want to have it pull your own package in (eg to provide site-configuration)</blockquote>
This is (a beginning of) a case study into dependencies which cannot be properly, or often at all, expressed with the current static provides/requires/conflicts/obsoletes dependencies of rpm.
Not a feature in rpm.
Interesting page, to see we’re not the only ones having trouble with this.
Its probably best if the dependency workarond for things like the VPN ( that need removal of uwt) are done by a script with a wizard front-end. That way users won’t be confused or shoot themselves in the foot.
You can’t hope to do this for every meta-package in Whonix without upstrem support for such a feature but at least the common supported use cases will be handled safely.
How likely is it that Debian upstream will add the dependency changes you are looking for if I tell them about it? Would it need large changes to apt and what it does now?
How likely is it that Debian upstream will add the dependency changes you are looking for if I tell them about it?
Very low and after having wrapped my head about this, I don't even know how to work around this for Whonix's own meta packages.
Would it need large changes to apt and what it does now?
Yes. It's a known issue. To fix this, you'd need a great concept on how to fix it + proof of concept implementation + very good social skills to get agreement from the debian developers. I have little hope it's happening anytime soon.
By then, any other attempt to apt-get install, dist-upgrade or remove would fail until one runs sudo apt-get install -f. That would fix it (and reinstall uwt). However, if one can live with that, this may be an acceptable workaround.
Debian packages support only Recommends: or Depends: . There is nothing in the middle. The missing feature is:
Weak-Depends: list of packages that gets installed when using apt --no-install-recommends but any package listed there can be removed without removing the package which referenced the Weak-Depends:
It would be useful if there was something in between of Recommends: and Depends:.
“Weak-Depends”
Similar to “Depends”. List of packages that gets installed when using apt --no-install-recommends meta-package but any package listed there can be removed without removing the meta-package which referenced the Weak-Depends:.
In other words…
“Weak-Depends”: This declares a weak dependency. Many users of this package may benefit from installing packages listed in this field but can have reasonable functions without them.
The “Suggests” debian/control field does not work for this use case. Very few users are using ‘apt --install-suggests’. And ‘apt --no-install-suggests’ is the default. Also when using ‘apt dist-upgrade’ this leads to inconsistencies:
newly added packages to “Suggests” are not installed
removed packages from “Suggests” aren’t removed
Use case:
Let’s take for example the meta package ‘lxde’. Sometimes users are happy with such meta packages generally and would like to keep it. However, ‘lxde’ ‘Depends:’ on ‘galculator’. Maybe a user prefers a different calculator and wants to remove that one.
(Let’s assume galculator isn’t essential for lxde. I guess it is. But if it isn’t, please don’t concentrate on the specific example but the general use case. There are many such examples.)
[This isn’t the best example too. Perhaps things that take a lot disk space or are more intrusive such as context menu integrations by file compressors are more worthwhile.]
In that case removal of galculator would lead to removal of lxde. Next time “apt autoremove” is being run other packages which are not intended by the user to be uninstalled get uninstalled. Something simple as removal of galculator isn’t that simple. Would galculator move from “Depends” to “Weak-Depends” everything would be perfect.
It would be useful if there was something in between of Recommends: and Depends:.
“Weak-Depends”
Similar to “Depends”. It lists packages that get installed when using apt --no-install-recommends meta-package, but any package listed there can be removed without removing the meta-package which referenced the Weak-Depends:.
In other words…
“Weak-Depends”: Declares a weak dependency. Most users of this package may benefit from installing packages listed in this field, but can have reasonable functionality without them.
The “Suggests” debian/control field does not work for this use case. Very few users are using ‘apt --install-suggests’. And ‘apt --no-install-suggests’ is the default. Also when using ‘apt dist-upgrade’ this leads to inconsistencies:
newly added packages to “Suggests” are not installed
removed packages from “Suggests” aren’t removed
Use case:
Let’s take for example the meta package ‘lxde’. Sometimes users are happy with such meta packages generally and would like to keep it. However, ‘lxde’ ‘Depends:’ on ‘galculator’. Maybe a user prefers a different calculator and wants to remove that one.
(Let’s assume galculator isn’t essential for lxde. I guess it is. But if it isn’t, please don’t concentrate on the specific example but the general use case. There are many such examples.)
[This isn’t the best example too. Perhaps things that take a lot disk space or are more intrusive such as context menu integrations by file compressors are more worthwhile.]
In that case removal of galculator would lead to removal of lxde. Next time “apt autoremove” is being run other packages which are not intended by the user to be uninstalled get uninstalled. Something simple as removal of galculator isn’t that simple. Would galculator move from “Depends” to “Weak-Depends” everything would be perfect.