Add meta-packages for installing Qubes related packages in VMs

[marmarek]

Currently builder plugins have hardcoded list of packages to install in templates and additional packages are installed as dependencies of qubes-core-agent/qubes-core-vm package. This is sub optimal for various reasons:

1. Makes hard for builder plugins to support multiple Qubes versions at the same time (for example builder-debian master branch currently can't build R3.1 template, because qubes-mgmt-salt-vm-connector package isn't available there)
2. Unrelated packages are pulled in as dependencies for qubes-core-agent, which make it hard to remove them - for example to make minimal template (for Fedora minimal template we have "stub" package to install instead of some "required" packages, which is really awful hack)

The second point additionally would require splitting qubes-core-agent package as a next step. But lets start with something.

[marmarek]

@adrelanos any recommendations here? I see Whonix have https://github.com/Whonix/anon-meta-packages
I think we need just two packages:

• qubes-meta-required
• qubes-meta-recommended

(or maybe different names? like qubes-vm-required?)

[marmarek]

@adrelanos any recommendations here? I see Whonix have https://github.com/Whonix/anon-meta-packages
I think we need just two packages:

• qubes-meta-required
• qubes-meta-recommended

(or maybe different names? like qubes-vm-required?)

[adrelanos]

• qubes-dom0-dependencies
• qubes-dom0-recommended
• qubes-vm-dependencies
• qubes-vm-recommended
• And also a package that depends on both of them, qubes-dom0 / qubes-vm?

There is one major issue with meta packages in Debian. There is no such thing as weak dependencies in Debian.

It depends on which packages end up in status "manually installed". Let's say qubes-vm has status "manually installed" and qubes-vm-required not. Once users remove some package that is listed as dependency of qubes-vm-recommended, it will remove qubes-dom0-recommended. So far so good. But it would also remove qubes-vm. And then qubes-vm-required would not have status "manually installed". During the next run of apt-get autoremove that package and all packages it depends on would be uninstalled and thereby breaking Qubes.

This mess is described a bit more in detail here:
https://www.whonix.org/wiki/Whonix_Debian_Packages

[adrelanos]

• qubes-dom0-dependencies
• qubes-dom0-recommended
• qubes-vm-dependencies
• qubes-vm-recommended
• And also a package that depends on both of them, qubes-dom0 / qubes-vm?

There is one major issue with meta packages in Debian. There is no such thing as weak dependencies in Debian.

It depends on which packages end up in status "manually installed". Let's say qubes-vm has status "manually installed" and qubes-vm-required not. Once users remove some package that is listed as dependency of qubes-vm-recommended, it will remove qubes-dom0-recommended. So far so good. But it would also remove qubes-vm. And then qubes-vm-required would not have status "manually installed". During the next run of apt-get autoremove that package and all packages it depends on would be uninstalled and thereby breaking Qubes.

This mess is described a bit more in detail here:
https://www.whonix.org/wiki/Whonix_Debian_Packages

[marmarek]

What about using Recommends: or Suggests: dependencies?
Recently something similar was introduced in Fedora.
Anyway, this is partially the reason why I've listed only -recommended and -required (or -dependencies), without meta package over them - to install both of them by template builder/installer so both will have status "manually installed" and will mitigate this problem. And probably for minimal template, only -dependencies will be installed.

[marmarek]

What about using Recommends: or Suggests: dependencies?
Recently something similar was introduced in Fedora.
Anyway, this is partially the reason why I've listed only -recommended and -required (or -dependencies), without meta package over them - to install both of them by template builder/installer so both will have status "manually installed" and will mitigate this problem. And probably for minimal template, only -dependencies will be installed.

[adrelanos]

Marek Marczykowski-Górecki:

What about using `Recommends:` or `Suggests:` dependencies?

`Suggests:` is a nice to have, but does not actually do stuff. Only when you install stuff on the command line, it textually suggests other related packages you might be interested in. Just for informational purposes. (There is no want to install yes/no.) It however won't ever automatically install those. (Unless using --install-suggests but I've never seen that referenced anywhere.) `Recommends:` is to be used with care, it leads to inconsistent results for people who got the package at different times when `Recommends:` changed. When you install a new package using apt-get (without --no-install-recommends) it will by default fetch any package under `Recommends:`. However, when later the list of packages under `Recommends:` changes and the package is upgraded, the user won't notice a thing. It's even hard to "complete" getting the new/changed `Recommends:`. I happened to uninstall and reinstall a package to get consistent `Recommends:`.

Recently something similar was introduced in Fedora. Anyway, this is partially the reason why I've listed only `-recommended` and `-required` (or `-dependencies`), without meta package over them - to install both of them by template builder/installer so both will have status "manually installed" and will mitigate this problem. And probably for minimal template, only `-dependencies` will be installed.

Sounds good.

[adrelanos]

Marek Marczykowski-Górecki:

What about using `Recommends:` or `Suggests:` dependencies?

`Suggests:` is a nice to have, but does not actually do stuff. Only when you install stuff on the command line, it textually suggests other related packages you might be interested in. Just for informational purposes. (There is no want to install yes/no.) It however won't ever automatically install those. (Unless using --install-suggests but I've never seen that referenced anywhere.) `Recommends:` is to be used with care, it leads to inconsistent results for people who got the package at different times when `Recommends:` changed. When you install a new package using apt-get (without --no-install-recommends) it will by default fetch any package under `Recommends:`. However, when later the list of packages under `Recommends:` changes and the package is upgraded, the user won't notice a thing. It's even hard to "complete" getting the new/changed `Recommends:`. I happened to uninstall and reinstall a package to get consistent `Recommends:`.

Recently something similar was introduced in Fedora. Anyway, this is partially the reason why I've listed only `-recommended` and `-required` (or `-dependencies`), without meta package over them - to install both of them by template builder/installer so both will have status "manually installed" and will mitigate this problem. And probably for minimal template, only `-dependencies` will be installed.

Sounds good.

[marmarek]

On Fri, Jan 13, 2017 at 06:30:27AM -0800, Patrick Schleizer wrote: `Recommends:` is to be used with care, it leads to inconsistent results for people who got the package at different times when `Recommends:` changed. When you install a new package using apt-get (without --no-install-recommends) it will by default fetch any package under `Recommends:`. However, when later the list of packages under `Recommends:` changes and the package is upgraded, the user won't notice a thing. It's even hard to "complete" getting the new/changed `Recommends:`. I happened to uninstall and reinstall a package to get consistent `Recommends:`.

Ah I see. So indeed not good here.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

On Fri, Jan 13, 2017 at 06:30:27AM -0800, Patrick Schleizer wrote: `Recommends:` is to be used with care, it leads to inconsistent results for people who got the package at different times when `Recommends:` changed. When you install a new package using apt-get (without --no-install-recommends) it will by default fetch any package under `Recommends:`. However, when later the list of packages under `Recommends:` changes and the package is upgraded, the user won't notice a thing. It's even hard to "complete" getting the new/changed `Recommends:`. I happened to uninstall and reinstall a package to get consistent `Recommends:`.

Ah I see. So indeed not good here.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[unman]

@adrelanos It's true that apt-get is not good at keeping track of, and working with, dependency and recommend changes. That's why it's generally better to use apt or aptitude which do do the right thing. In fact promoting the use of these tools, particularly aptitude, would, I think, resolve all the issues that you raise, particularly "the user won't notice a thing.".
Of course, just because it's displayed, doesn't mean the user will notice, but that's a separate issue.
Using aptitude will definitely resolve the "inconsistent results" issue you raise about using recommends.

All of which is a long winded approach to saying that using "Recommends" would be a workable solution here imo. Does that work the same way in Fedora?

Looking back at the early discussion of packaging it seems to me that many of the decisions (eg inclusion of pulse audio as dependency) were made to provide the simplest user experience, and to avoid users installing Qubes with no sound. That imperative has changed, and so the rationale for including packages as dependencies has gone.

[unman]

@adrelanos It's true that apt-get is not good at keeping track of, and working with, dependency and recommend changes. That's why it's generally better to use apt or aptitude which do do the right thing. In fact promoting the use of these tools, particularly aptitude, would, I think, resolve all the issues that you raise, particularly "the user won't notice a thing.".
Of course, just because it's displayed, doesn't mean the user will notice, but that's a separate issue.
Using aptitude will definitely resolve the "inconsistent results" issue you raise about using recommends.

All of which is a long winded approach to saying that using "Recommends" would be a workable solution here imo. Does that work the same way in Fedora?

Looking back at the early discussion of packaging it seems to me that many of the decisions (eg inclusion of pulse audio as dependency) were made to provide the simplest user experience, and to avoid users installing Qubes with no sound. That imperative has changed, and so the rationale for including packages as dependencies has gone.

[adrelanos]

unman:

@adrelanos It's true that apt-get is not good at keeping track of, and working with, dependency and recommend changes.

Dependency tracking works flawless with apt-get. There is no way to miss a 'Depends:' package during upgrades.

That's why it's generally better to use apt

apt? Looks pretty certain, that they are just different front-ends and sharing the same backend for dependency resolving etc. https://mvogt.wordpress.com/2014/04/04/apt-1-0/

or aptitude which *do* do the right thing. In fact promoting the use of these tools, particularly aptitude, would, I think, resolve all the issues that you raise, particularly "the user won't notice a thing.".Of course, just because it's displayed, doesn't mean the user will notice, but that's a separate issue. Using aptitude will definitely resolve the "inconsistent results" issue you raise about using recommends.

https://wiki.debian.org/Aptitude says aptitude is a front-end to apt. https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal lists quite some aptitude caveats. Does not seem to be a drop-in 100% replacement for apt-get. And recommending both apt-get and aptitude to users I would guess would worsen usability. Writing this post made me look closer at aptitude. Certainly has some useful features for developers. Features like aptitude why-not <regex> might certainly make development easier.

[adrelanos]

unman:

@adrelanos It's true that apt-get is not good at keeping track of, and working with, dependency and recommend changes.

Dependency tracking works flawless with apt-get. There is no way to miss a 'Depends:' package during upgrades.

That's why it's generally better to use apt

apt? Looks pretty certain, that they are just different front-ends and sharing the same backend for dependency resolving etc. https://mvogt.wordpress.com/2014/04/04/apt-1-0/

or aptitude which *do* do the right thing. In fact promoting the use of these tools, particularly aptitude, would, I think, resolve all the issues that you raise, particularly "the user won't notice a thing.".Of course, just because it's displayed, doesn't mean the user will notice, but that's a separate issue. Using aptitude will definitely resolve the "inconsistent results" issue you raise about using recommends.

https://wiki.debian.org/Aptitude says aptitude is a front-end to apt. https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal lists quite some aptitude caveats. Does not seem to be a drop-in 100% replacement for apt-get. And recommending both apt-get and aptitude to users I would guess would worsen usability. Writing this post made me look closer at aptitude. Certainly has some useful features for developers. Features like aptitude why-not <regex> might certainly make development easier.

[unman]

Dependency tracking works flawless with apt-get. There is no way to miss a 'Depends:' package during upgrades.

But it's far easier to resolve dependency hell with aptitude. And it resolves the issues you complain of with recommends, which is the point here.

apt? Looks pretty certain, that they are just different front-ends and sharing the same backend for dependency resolving etc.

Yes, they are all different front-ends - I'm not sure what your point is. apt is the most recommended user front end, aptitude the most versatile.

Anyway, I don't want to get in to religious wars about this. For most users, using aptitude (or some other high level tool), will avoid the problems you point to re use of "recommends", and I suggest that's the way we should go.

@marmarek Does the Fedora usage you refer to earlier work in the same way as Debian?

[unman]

Dependency tracking works flawless with apt-get. There is no way to miss a 'Depends:' package during upgrades.

But it's far easier to resolve dependency hell with aptitude. And it resolves the issues you complain of with recommends, which is the point here.

apt? Looks pretty certain, that they are just different front-ends and sharing the same backend for dependency resolving etc.

Yes, they are all different front-ends - I'm not sure what your point is. apt is the most recommended user front end, aptitude the most versatile.

Anyway, I don't want to get in to religious wars about this. For most users, using aptitude (or some other high level tool), will avoid the problems you point to re use of "recommends", and I suggest that's the way we should go.

@marmarek Does the Fedora usage you refer to earlier work in the same way as Debian?

[marmarek]

Fedora got Recommends: rather recently - Fedora >= 24. I have not idea how it works yet...

[marmarek]

Fedora got Recommends: rather recently - Fedora >= 24. I have not idea how it works yet...

[marmarek]

@unman can you provide an example how apt or aptitude handle expanded Recommends:. Say package1 version 1.0 recommends package2. Then package1 version 2.0 recommends also package3. How does upgrade of package1 work in default setup (without any additional options etc)? Exact console output preferred.

[marmarek]

@unman can you provide an example how apt or aptitude handle expanded Recommends:. Say package1 version 1.0 recommends package2. Then package1 version 2.0 recommends also package3. How does upgrade of package1 work in default setup (without any additional options etc)? Exact console output preferred.

[unman]

@andrewdavidwong Confirmed this issue still arises in 3.2 milestone.
I see it's waiting for input from me, so I'll pick that up later.

[unman]

@andrewdavidwong Confirmed this issue still arises in 3.2 milestone.
I see it's waiting for input from me, so I'll pick that up later.

[marmarek]

For Fedora VMs (and maybe dom0, as long as it's Fedora-based?) it looks like groups is what we need. From dnf manpage:

dnf [options] group upgrade <group-spec>...
Upgrades the packages from the group and upgrades the group itself. The latter comprises of installing pacakges that were added to the group by the distribution and removing packages that got removed from the group as far as they were not installed explicitly by the user.

In fact, Fedora template build process do use group to specify what packages should be installed. But that information isn't populated into package repository.

[marmarek]

For Fedora VMs (and maybe dom0, as long as it's Fedora-based?) it looks like groups is what we need. From dnf manpage:

dnf [options] group upgrade <group-spec>...
Upgrades the packages from the group and upgrades the group itself. The latter comprises of installing pacakges that were added to the group by the distribution and removing packages that got removed from the group as far as they were not installed explicitly by the user.

In fact, Fedora template build process do use group to specify what packages should be installed. But that information isn't populated into package repository.

[jpouellet]

Cross-referencing for easier tracking:

Note that dom0 packages may benefit from an equivalent meta package as well. Selecting only the top-level qubes metapackage in the installer and letting everything else be pulled in automatically as a dependency might perhaps be a large part of the solution to #2742.

[jpouellet]

Cross-referencing for easier tracking:

Note that dom0 packages may benefit from an equivalent meta package as well. Selecting only the top-level qubes metapackage in the installer and letting everything else be pulled in automatically as a dependency might perhaps be a large part of the solution to #2742.

[marmarek]

Meta-packages implemented here: https://github.com/QubesOS/qubes-meta-packages
For now only for VM.

[marmarek]

Meta-packages implemented here: https://github.com/QubesOS/qubes-meta-packages
For now only for VM.

[marmarek]

@adrelanos this ticket (and #2771) require some coordination with Whonix.

See package split outcome: QubesOS/qubes-meta-packages@3d5b0aa
Since Whonix by default do not install Recommended: packages, none of them will be installed in Whonix - so for example no dom0 updates handling, and no updates proxy.
Meta packages linked above are Qubes-version specific, but I'm not sure how to handle this at Whonix side to support both Qubes 3.2 and Qubes 4.0. If that would help, we can add another meta-package with something between full and minimal one.

[marmarek]

@adrelanos this ticket (and #2771) require some coordination with Whonix.

See package split outcome: QubesOS/qubes-meta-packages@3d5b0aa
Since Whonix by default do not install Recommended: packages, none of them will be installed in Whonix - so for example no dom0 updates handling, and no updates proxy.
Meta packages linked above are Qubes-version specific, but I'm not sure how to handle this at Whonix side to support both Qubes 3.2 and Qubes 4.0. If that would help, we can add another meta-package with something between full and minimal one.

[adrelanos]

Whonix-Gateway should depend on:

• qubes-vm-dependencies
• qubes-core-agent-dom0-updates
• qubes-core-agent-nautilus
• qubes-core-agent-networking
• Not depend on qubes-core-agent-network-manager since only useful in sys-net?

Whonix-Workstation should depend on:

• qubes-vm-dependencies
• pulseaudio-qubes
• Not depend on qubes-core-agent-dom0-updates because sys-whonix will be UpdateVM?
• qubes-core-agent-nautilus
• qubes-core-agent-networking
• Not depend on qubes-core-agent-network-manager since only useful in sys-net?
• Not on qubes-gpg-split?
• Not on qubes-img-converter?
• Not on qubes-pdf-converter?
• qubes-thunderbird

Right? Could you please create a list on what you think is useful for the gateway and workstation?

Will there still be qubes-core-agent-linux?

What would probably work is:

Depends: qubes-vm-dependencies | some-package-that-only-exists-in-Qubes-R3.2,

• qubes-core-agent-dom0-updates | some-package-that-only-exists-in-Qubes-R3.2,

That means, if qubes-vm-dependencies is available (Qubes R4), depend on that. Otherwise depend on some-package-that-only-exists-in-Qubes-R3.2. And some-package-that-only-exists-in-Qubes-R3.2 could be qubes-core-agent-linux?

[adrelanos]

Whonix-Gateway should depend on:

• qubes-vm-dependencies
• qubes-core-agent-dom0-updates
• qubes-core-agent-nautilus
• qubes-core-agent-networking
• Not depend on qubes-core-agent-network-manager since only useful in sys-net?

Whonix-Workstation should depend on:

• qubes-vm-dependencies
• pulseaudio-qubes
• Not depend on qubes-core-agent-dom0-updates because sys-whonix will be UpdateVM?
• qubes-core-agent-nautilus
• qubes-core-agent-networking
• Not depend on qubes-core-agent-network-manager since only useful in sys-net?
• Not on qubes-gpg-split?
• Not on qubes-img-converter?
• Not on qubes-pdf-converter?
• qubes-thunderbird

Right? Could you please create a list on what you think is useful for the gateway and workstation?

Will there still be qubes-core-agent-linux?

What would probably work is:

Depends: qubes-vm-dependencies | some-package-that-only-exists-in-Qubes-R3.2,

• qubes-core-agent-dom0-updates | some-package-that-only-exists-in-Qubes-R3.2,

That means, if qubes-vm-dependencies is available (Qubes R4), depend on that. Otherwise depend on some-package-that-only-exists-in-Qubes-R3.2. And some-package-that-only-exists-in-Qubes-R3.2 could be qubes-core-agent-linux?

[h01ger]

On Wed, Jun 07, 2017 at 06:30:23PM -0700, Patrick Schleizer wrote: Whonix-Workstation should depend on: * pulseaudio-qubes * qubes-core-agent-nautilus * qubes-thunderbird

I was going to suggest that these should be recommends and then while writing this mail I realized that whonix doesnt install recommends… my point is: I never use nautilus nor thunderbird on whonix and would like to be able to easily remove them, without resorting to equivs. And sometimes I'm also not interested in having sound in whonix workstation VMs… not sure how to achieve this…

…

-- cheers, Holger

[h01ger]

On Wed, Jun 07, 2017 at 06:30:23PM -0700, Patrick Schleizer wrote: Whonix-Workstation should depend on: * pulseaudio-qubes * qubes-core-agent-nautilus * qubes-thunderbird

I was going to suggest that these should be recommends and then while writing this mail I realized that whonix doesnt install recommends… my point is: I never use nautilus nor thunderbird on whonix and would like to be able to easily remove them, without resorting to equivs. And sometimes I'm also not interested in having sound in whonix workstation VMs… not sure how to achieve this…

…

-- cheers, Holger

[marmarek]

Whonix-Gateway should depend on:

qubes-vm-dependencies
qubes-core-agent-dom0-updates
qubes-core-agent-nautilus

Is this really needed in gateway?

qubes-core-agent-networking
Not depend on qubes-core-agent-network-manager since only useful in sys-net?

Whonix-Workstation should depend on:

qubes-vm-dependencies
pulseaudio-qubes
Not depend on qubes-core-agent-dom0-updates because sys-whonix will be UpdateVM?
qubes-core-agent-nautilus
qubes-core-agent-networking
Not depend on qubes-core-agent-network-manager since only useful in sys-net?
Not on qubes-gpg-split?
Not on qubes-img-converter?
Not on qubes-pdf-converter?
qubes-thunderbird

This looks ok.

Will there still be qubes-core-agent-linux?

You mean qubes-core-agent. Yes, only some (optional) parts were separated into separate packages.

Depends: qubes-vm-dependencies | some-package-that-only-exists-in-Qubes-R3.2,

Actually to make it easier, I've already uploaded qubes-vm-dependencies to R3.2 repository. It depends on qubes-core-agent and qubes-gui-agent, so this part looks the same on R3.2 and R4.0.
The problematic part is about other packages not existing in R3.2.

qubes-core-agent-dom0-updates | some-package-that-only-exists-in-Qubes-R3.2,

Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent.

[marmarek]

Whonix-Gateway should depend on:

qubes-vm-dependencies
qubes-core-agent-dom0-updates
qubes-core-agent-nautilus

Is this really needed in gateway?

qubes-core-agent-networking
Not depend on qubes-core-agent-network-manager since only useful in sys-net?

Whonix-Workstation should depend on:

qubes-vm-dependencies
pulseaudio-qubes
Not depend on qubes-core-agent-dom0-updates because sys-whonix will be UpdateVM?
qubes-core-agent-nautilus
qubes-core-agent-networking
Not depend on qubes-core-agent-network-manager since only useful in sys-net?
Not on qubes-gpg-split?
Not on qubes-img-converter?
Not on qubes-pdf-converter?
qubes-thunderbird

This looks ok.

Will there still be qubes-core-agent-linux?

You mean qubes-core-agent. Yes, only some (optional) parts were separated into separate packages.

Depends: qubes-vm-dependencies | some-package-that-only-exists-in-Qubes-R3.2,

Actually to make it easier, I've already uploaded qubes-vm-dependencies to R3.2 repository. It depends on qubes-core-agent and qubes-gui-agent, so this part looks the same on R3.2 and R4.0.
The problematic part is about other packages not existing in R3.2.

qubes-core-agent-dom0-updates | some-package-that-only-exists-in-Qubes-R3.2,

Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent.

[adrelanos]

Holger Levsen:

my point is: I never use nautilus nor thunderbird on whonix and would like to be able to easily remove them, without resorting to equivs. And sometimes I'm also not interested in having sound in whonix workstation VMs… not sure how to achieve this…

Could you explain 'weak dependencies' to the apt developers and post a Debian feature request please? Marek Marczykowski-Górecki:

> Whonix-Gateway should depend on: > > qubes-vm-dependencies > qubes-core-agent-dom0-updates > qubes-core-agent-nautilus Is this really needed in gateway?

qubes-vm-dependencies: yes, since it depends qubes-core-agent, qubes-gui-agent, sudo, systemd? qubes-core-agent-dom0-updates: It's purpose is functioning as UpdateVM for dom0, right? Then yes. qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes.

> qubes-core-agent-dom0-updates |

some-package-that-only-exists-in-Qubes-R3.2,

Yes, something like this. I don't think we have

"some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent. Sounds good.

[adrelanos]

Holger Levsen:

my point is: I never use nautilus nor thunderbird on whonix and would like to be able to easily remove them, without resorting to equivs. And sometimes I'm also not interested in having sound in whonix workstation VMs… not sure how to achieve this…

Could you explain 'weak dependencies' to the apt developers and post a Debian feature request please? Marek Marczykowski-Górecki:

> Whonix-Gateway should depend on: > > qubes-vm-dependencies > qubes-core-agent-dom0-updates > qubes-core-agent-nautilus Is this really needed in gateway?

qubes-vm-dependencies: yes, since it depends qubes-core-agent, qubes-gui-agent, sudo, systemd? qubes-core-agent-dom0-updates: It's purpose is functioning as UpdateVM for dom0, right? Then yes. qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes.

> qubes-core-agent-dom0-updates |

some-package-that-only-exists-in-Qubes-R3.2,

Yes, something like this. I don't think we have

"some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent. Sounds good.

[marmarek]

Is this really needed in gateway?

I had in mind only the last one.

qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes.

I mean does Whonix Gateway need a file manager at all?

Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent.

Sounds good.

Any idea for it's name? qubes-vm-r3.2?
Or, maybe it isn't needed at all, what about:

Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0)

[marmarek]

Is this really needed in gateway?

I had in mind only the last one.

qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes.

I mean does Whonix Gateway need a file manager at all?

Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent.

Sounds good.

Any idea for it's name? qubes-vm-r3.2?
Or, maybe it isn't needed at all, what about:

Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0)

[adrelanos]

Marek Marczykowski-Górecki:

>> Is this really needed in gateway? I had in mind only the last one. > qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes. I mean does Whonix Gateway need a file manager at all?

It has one now. I think it's useful to have to navigate around, check out config/modify files. It's all doable from command line, but usability with file manager is better.

>> Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent. > > Sounds good. Any idea for it's name? `qubes-vm-r3.2`?

`qubes-vm-r3.2` sounds fine.

Or, maybe it isn't needed at all, what about: ``` Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0) ```

As long as qubes-vm-dependencies 4.0.0 exists in R3.2, that should work. I am not sure when upgrading to R4 if ` Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0)` would switch to installing "qubes-core-agent-dom0-updates" or regard the dependency solved since "qubes-vm-dependencies" already is installed. Do you know this, Holger?

[adrelanos]

Marek Marczykowski-Górecki:

>> Is this really needed in gateway? I had in mind only the last one. > qubes-core-agent-nautilus: Maybe could be avoided if we just install dolphin and qubes-core-agent-dolphin? I however would suggest qubes-core-agent-dolphin, to have file manage integration, in case someone wants to send a file from Whonix-Gateway to another VM for debugging/backup purposes. I mean does Whonix Gateway need a file manager at all?

It has one now. I think it's useful to have to navigate around, check out config/modify files. It's all doable from command line, but usability with file manager is better.

>> Yes, something like this. I don't think we have "some-package-that-only-exists-in-Qubes-R3.2" right now. But we can invent one. It can be empty package - since actual content needed [qubes-core-agent-dom0-updates] will be installed as part of qubes-core-agent. > > Sounds good. Any idea for it's name? `qubes-vm-r3.2`?

`qubes-vm-r3.2` sounds fine.

Or, maybe it isn't needed at all, what about: ``` Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0) ```

As long as qubes-vm-dependencies 4.0.0 exists in R3.2, that should work. I am not sure when upgrading to R4 if ` Depends: qubes-core-agent-dom0-updates | qubes-vm-dependencies (<< 4.0.0)` would switch to installing "qubes-core-agent-dom0-updates" or regard the dependency solved since "qubes-vm-dependencies" already is installed. Do you know this, Holger?

[h01ger]

On Thu, Jun 08, 2017 at 05:57:22AM -0700, Patrick Schleizer wrote: > my point is: I never use nautilus nor thunderbird on whonix and would like to > be able to easily remove them, without resorting to equivs. And sometimes I'm > also not interested in having sound in whonix workstation VMs… > > not sure how to achieve this… Could you explain 'weak dependencies' to the apt developers and post a Debian feature request please?

what should weak dependencies be? recommends whonix would like to install? ;-) couldn't this be solved by having a package, say whonix-recommends, and this one, and only this one, is initially installed using apt install --with-recommends?!

…

-- cheers, Holger

[h01ger]

On Thu, Jun 08, 2017 at 05:57:22AM -0700, Patrick Schleizer wrote: > my point is: I never use nautilus nor thunderbird on whonix and would like to > be able to easily remove them, without resorting to equivs. And sometimes I'm > also not interested in having sound in whonix workstation VMs… > > not sure how to achieve this… Could you explain 'weak dependencies' to the apt developers and post a Debian feature request please?

what should weak dependencies be? recommends whonix would like to install? ;-) couldn't this be solved by having a package, say whonix-recommends, and this one, and only this one, is initially installed using apt install --with-recommends?!

…

-- cheers, Holger

[adrelanos]

It's more messy than that. Weak dependencies really is a missing apt feature. Details: https://www.whonix.org/wiki/Whonix_Debian_Packages#Technical_Stuff

[adrelanos]

It's more messy than that. Weak dependencies really is a missing apt feature. Details: https://www.whonix.org/wiki/Whonix_Debian_Packages#Technical_Stuff

[adrelanos]

Whonix work tracked here.
sort out meta packages compatiblity with Qubes 3.2 and Qubes R4.0
https://phabricator.whonix.org/T697

[adrelanos]

Whonix work tracked here.
sort out meta packages compatiblity with Qubes 3.2 and Qubes R4.0
https://phabricator.whonix.org/T697