search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 47 forks source link

qubes-vm-recommended packages are non-optional #6855

Closed 3hhh closed 3 years ago

3hhh commented 3 years ago

The problem you're addressing (if any)

Opting out from certain "recommended" packages is impossible for a user, e.g. on debian-10:

apt-get install qubes-vm-recommended haveged-
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 qubes-vm-recommended : Depends: haveged but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

The solution you'd like

Mark optional packages as optional so that the user can opt out.

The value to a user, and who that user might be

Uninstall unused packages without having to remove qubes-vm-recommended entirely, possibly taking away currently used parts of it.

E.g. apt-get install qubes-vm-recommended, followed by apt-get purge haveged will uninstall qubes-vm-recommended and mark its dependencies for removal on the next apt-get autoremove.

marmarek commented 3 years ago

This one is tricky, I'm afraid. We want to handle upgrades properly too - qubes-vm-recommended should be able to bring new dependencies (like jitterentropy-rng proposed in the other thread). Last time I checked, it doesn't work reliably with Recommends: dependency type. That's why we have two meta-packages - one with strictly required packages (qubes-vm-dependencies) and another one with optional ones. You can remove the latter, but then you need to manually ensure you keep applications you want.

andrewdavidwong commented 3 years ago

This one is tricky, I'm afraid. We want to handle upgrades properly too - qubes-vm-recommended should be able to bring new dependencies (like jitterentropy-rng proposed in the other thread). Last time I checked, it doesn't work reliably with Recommends: dependency type. That's why we have two meta-packages - one with strictly required packages (qubes-vm-dependencies) and another one with optional ones. You can remove the latter, but then you need to manually ensure you keep applications you want.

Does that mean this is a "won't do"?

marmarek commented 3 years ago

Yes, unless someone has a better idea...

unman commented 3 years ago

On Mon, Aug 23, 2021 at 05:06:33PM -0700, Marek Marczykowski-Górecki wrote:

Yes, unless someone has a better idea...

I cant think of a better idea.

In any case, the reasoning behind the report is misplaced. It's not that "qubes-vm-recommended packages are non-optional" - they obviously are. And you can select a subset of those packages as you will. What you cant do is choose to install this package, and not have the dependencies. This is standard fare in Debian. You cannot (e.g) install libreoffice and opt out from libreoffice-impress - it's a dependency of the libreoffice metapackage.

3hhh commented 3 years ago

Fair enough. Then please close as won't do.

andrewdavidwong commented 3 years ago

Closing as "won't do." If anyone has a new reason for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.

adrelanos commented 3 years ago

The technical issue is elaborated here: https://www.whonix.org/wiki/Whonix_Debian_Packages#Technical_Information

Debian feature request: Weak-Depends - something in the middle between 'Recommends:' and 'Depends:'

@DemiMarie did a great job of implementing APT reliable exit codes. Perhaps this is also something which you would like to implement?

DemiMarie commented 3 years ago

@DemiMarie did a great job of implementing APT reliable exit codes. Perhaps this is also something which you would like to implement?

My patch didn’t actually get accepted ― it just caused Julian to write a correct implementation. I imagine that something similar would happen here; I am not very familiar with APT internals.