Originally published at: https://www.whonix.org/blog/consolidating-whonix-packages
There have been some complaints, that there are too many Whonix packages. Specifically by people auditing or trying to understand Whonix better. I think here is some valid and some invalid criticism. Nowadays seemlingly almost everyone is overworked. Attention spawns are small. However, it should not be expected to be capable to get an overview about a linux distribution in 5 minutes. All I can do is ask to take 30 or 60 minutes to go through the list of Whonix packages one by one. Perhaps just read the quick github description. And if you want to learn more, see their readme files. That should give you a good first overview.
Okay, perhaps 120 packages is a bit much. And a bit can and will be consolidated.
The days of Whonix with KDE by default are counted anyhow.
Perhaps with Whonix 14, Whonix will be ported to GNOME. I don’t care so much about KDE above GNOME anymore. And GNOME provides better accessibility support for the blind. Qubes is changing to GNOME by default, so Whonix has to do that for Qubes-Whonix also. EDIT: instead Whonix was ported to XFCE
As a side effect, that way there will be ~16 kde- packages less. They will be removed from github.com/Whonix, thereby making the packages list smaller, and perhaps remain unmaintained under github.com/adrelanos for historic and whatever purpose.
Anyhow. Some packages could usefully be consolidated. For example, from today’s perspective I was a bit too eager to make a separate packages scurl and poweroff-passwordless. That could be merged into the usability-misc package?
On the other hand, a separate scurl package advertises better it’s functionality and good security practices.
What about curl-scripts?
Other suggestions for consolidation?
The absence of the dpkg feature ‘weak dependencies’ is also really sad. Since Whonix meta packages are removed just for uninstalling let’s say gpl-sources-download makes the split packages less worthwhile. That background is explained here and under technical stuff.
Split packages are still useful enough. For abstractions reasons. To make maintenance, audits and upstreaming easier.