qubes-issues
qubes-issues copied to clipboard
QubesOS
(Re)move Debian packages in `packages.list` and `packages_minimal.list`
What's the purpose of these files?
Why are some packages installed there?
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages.list
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages_minimal.list
full list:
ncurses-term
aptitude
tasksel
sudo
dmsetup
psmisc
gnupg
xterm
libfile-mimeinfo-perl
libglib2.0-bin
ltrace
strace
haveged
wireless-tools
wpasupplicant
dbus-x11
For example, having wpasupplicant there seems most obviously unnecessary. That results in the Whonix template having this package, although not required.
Wouldn't it be better if these packages where referenced in qubes meta packages?
We could move those to "vm-recommended" where the networking stuff is included. I dont think the rest are candidates for removal, but I'll check.
haveged nowadays only makes sense for older kernels as newer ones do its job inside the kernel, see #673.
Wireless tools removed here: https://github.com/QubesOS/qubes-builder-debian/pull/74
PR: Remove strace and ltrace
https://github.com/QubesOS/qubes-builder-debian/pull/75
PR: Remove haveged and dbus-x11
https://github.com/QubesOS/qubes-builder-debian/pull/77
The trace packages remain useful for troubleshooting, and have marginal impact. What is the reason for removing them?
I do not think haveged is unnecessary - it still has a place. dbus-x11 is marginal, but is of use for KDE. What is the (detailed) reason for wanting to remove them?
The trace packages remain useful for troubleshooting, and have marginal impact.
Thats the exact reason why they need to be removed. (read the title of the ticket)
I do not think haveged is unnecessary - it still has a place.
Needs evidence to be proven.
dbus-x11 is marginal, but is of use for KDE.
KDE is Wayland now, but nevertheless, it still requires evidence to be proven.
haveged is still useful for entropy with old kernels (e.g. some in-VM kernels). Admittedly these are uncommon configurations for Qubes OS, but they may happen.
It may be better to keep it and install a systemd condition to not start the daemon on newer kernels. The haveged author proposed just that a long time ago. Possibly it even made its way into debian by now - I haven't checked.
The trace packages remain useful for troubleshooting, and have marginal impact. What is the reason for removing them?
The idea of this ticket is to remove these packages from packages_minimal.list and if worthwhile, properly reintroduce these by adding these to a Qubes meta packages (qubes-meta-packages).
haveged is still useful for entropy with old kernels (e.g. some in-VM kernels). Admittedly these are uncommon configurations for Qubes OS, but they may happen.
Which distributions? In other words, how long do we have to carry this legacy?
It may be better to keep it and install a systemd condition to not start the daemon on newer kernels. The haveged author proposed just that a long time ago. Possibly it even made its way into debian by now - I haven't checked.
Seems a lot effort just to support some outdated (possibly already deprecated?) templates.
dbus-x11 is marginal, but is of use for KDE.
What's the benefit for dbus-x11?
If dbus-x11 is required, let's properly add it to a Qubes meta package instead?
Which distributions? In other words, how long do we have to carry this legacy?
Not debian for sure, debian bookworm DVD version (let alone CD version) doesnt has haveged by default.
What's the benefit for dbus-x11?
Zero benefit, Debian bookworm KDE-DVD version doesnt has dbus-x11 by default (let alone CD version).
So unless there is a critical reason why we should have these packages, they're just extra, useless packages not even included by default upstream.
Please, unless someone has proven evidence of the critical benefits of any of the removed packages, they can share it here. Otherwise, this is just spamming the ticket with outdated theories.
Why are people arguing about which non-Qubes packages are valuable, useful, or desirable for a Debian template? Isn't our policy about upstream distros intended to avoid precisely these sorts of arguments?
The minimal template intentionally deviate from this policy, to be as small base as possible. But this goes only one way - if a package isn't included in default package set of a distribution, surely it shouldn't be included in the minimal template either (unless needed by something qubes-specific, ofc).
The minimal template intentionally deviate from this policy, to be as small base as possible.
Yes, but in that case, it's still irrelevant whether a package is valuable, useful, or desirable. The standard for minimal templates isn't "be as small as possible while including all of the valuable, useful, and desirable stuff." It's just "be as small as possible."
In this case, "possible" really means something more like "practical" or "feasible." In other words, the minimal templates aim to be as small as possible while still serving their function as templates. So, people arguing over whether packages are valuable, useful, or desirable in the context of minimal templates are having the wrong debate. They must instead argue that the template will not work or will not be able to serve its purpose without the package in question, which is a much higher bar.
Thank you @marmarek @andrewdavidwong.
https://github.com/QubesOS/qubes-issues/issues/6566#issuecomment-1647610923 can we proceed so we i can post the next PR?
On Tue, Jul 23, 2024 at 03:23:29PM -0700, duck09 wrote:
What about the packages listed in this forum post?
You'll see that there was a discussion (brief) in qubes-devel, but the conclusion was that we should honor the distro in producing minimal templates. While it is possible to produce smaller templates (either by rebuilding with small package list or by package removal), these do not provide what Debian determines is the core of Debian. The same applies to Fedora.
The minimal template intentionally deviate from this policy, to be as small base as possible. But this goes only one way - if a package isn't included in default package set of a distribution, surely it shouldn't be included in the minimal template either (unless needed by something qubes-specific, ofc).
Does your answer not contradict the comment by marmarek earlier in this thread? This is unless the packages mentioned in the forum post are included by default, I am not sure if that is the case or not.
May I suggest to limit the scope of this ticket?
The scope being these two source code files only:
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages.list
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages_minimal.list
Packages listed there either being removed or moved to qubes meta packages.
This would be specifically useful in case of packages_minimal.list cleanup. Because then other distributions Templates built using qubes-builder-debian can have less packages installed by default.
If a package is not listed in these files, I would appreciate if that could be discussed in a different ticket, mailing list discussion or forum topic.
PR remove aptitude and tasksel:
https://github.com/QubesOS/qubes-builder-debian/pull/83
https://github.com/QubesOS/qubes-builder-debian/pull/83/commits/3552ef8168629b2fb70818074c0f4583388e0c7c
PR remove xterm and libfile-mimeinfo-perl:
https://github.com/QubesOS/qubes-builder-debian/pull/84
https://github.com/QubesOS/qubes-builder-debian/pull/84/commits/3724896d2a30a70d24307c4a584613af5ea5ee35
Is the inclusion of
gnupgandlibglib2.0-binnecessary?
https://github.com/QubesOS/qubes-builder-debian/pull/85
What's the purpose of these files?
Why are some packages installed there?
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages.list
- https://github.com/QubesOS/qubes-builder-debian/blob/master/template_debian/packages_minimal.list
full list:
ncurses-term aptitude tasksel sudo dmsetup psmisc gnupg xterm libfile-mimeinfo-perl libglib2.0-bin ltrace strace haveged wireless-tools wpasupplicant dbus-x11For example, having
wpasupplicantthere seems most obviously unnecessary. That results in the Whonix template having this package, although not required.Wouldn't it be better if these packages where referenced in qubes meta packages?
Is the Whonix template built from a minimal debian template?
Do you know if only the Gateway is based on the minimal template or is the Workstation based on it too?