Issues with removal of specific packages by users / builders


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.

For example, a common use case were users wish to tunnel all their traffic through something… ( https://www.whonix.org/wiki/Features#VPN_.2F_Tunnel_support )
uwt ( https://github.com/Whonix/uwt ) is a common source of confusion. ( https://github.com/Whonix/Whonix/issues/242 )

We cannot simply tell users to remove it. Unfortunately, it’s not all that simple. There are side effects.

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.


Case 3 (aka supplements)
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>


That page is a case study.

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.


Even a wizard/script should better not uninstall uwt. Disable it for a more robust solution. Let’s see how whonixsetup wizard develops. ( https://www.whonix.org/forum/index.php/topic,705.0.html ) And we got https://github.com/Whonix/Whonix/issues/242 as a note. Maybe some day.


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.


[quote=“nrgaway, post:1, topic:652”]Just get rid of the meta packages and use a micro-version of SaltStack, Chef or Puppet to manage the installation and removal of individual packages.

I could set up a Salt minion in a day or so that would be able to manage many scenarios. These management systems can install using the systems package manager or directly from git, pip, ftp, etc. They can also take care of any configurations that may be required.

It can be hard to wrap you head around what they actually can do for you and there is a steep learning curve if you don’t have anything to start with, but if someone like me provided a pretty much complete setup, you would then be able to very easily figure stuff out.

For instance, not that I am suggesting you do this at all, but to give an example to the configuration power they offer, Salt, Chef or Puppet could completely replace the existing Whonix installation where everything is handled by the management software including building VM’s, and the ability to deploy on multiple platforms as it has ability to map package names.

Anyway, just let me know if you want me to though a test system together for you to take a look at as its no bother for me to do so since I will be creating something for myself anyway. Just have to know what you want to see.

Maybe have a glace at Salts reference page, as that may give you an idea of what it can do http://docs.saltstack.com/en/latest/ref/index.html and most importantly its built in modules http://docs.saltstack.com/en/latest/ref/modules/all/index.html[/quote]
Split and will answer here:


Actually, there might be a very crude workaround.

sudo dpkg --purge --force-all uwt

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.