qubes-gui-agent might recommend, instead of depend on, pulseaudio?

[h01ger]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

Debian templates, though probably others are similar

Expected behavior:

I want to have more minimal Debian templates, without pulseaudio installed.

This could be done, if qubes-gui-agent would not depend on pulseaudio, and only recommended it instead.

(I might also want even more minimal templates, also without qubes-gui-agent, but thats another story…)

Actual behavior:

I wanted to have more minimal Debian templates, so I tried to remove pulseaudio, which also prompted me to remove qubes-gui-agent

Steps to reproduce the behavior:

sudo apt remove pulseaudio

General notes:

Qubes is awesome :)

Related issues:

[marmarek]

Related to #2572.
Probably not only require changing "depends" to "recommends" but also putting pulseaudio module into separate subpackage.

[marmarek]

Related to #2572.
Probably not only require changing "depends" to "recommends" but also putting pulseaudio module into separate subpackage.

[h01ger]

On Fri, Feb 24, 2017 at 04:11:09AM -0800, Marek Marczykowski-Górecki wrote: Related to #2572.

indeed, though this is much easier to solve :)

Probably not only require changing "depends" to "recommends" but also putting pulseaudio module into separate subpackage.

I'm not sure this useful/needed, even though this is cleaner: it will just move some bits to another package, say qubes-gui-agent-audio (or -pulseaudio?) but if this weren't done, those files would just be part if qubes-gui-agent package, without being used, but without harm too. Or were you thinking of moving more bits out of the package? I'd also be happy to provide patches for whatever functionality you'd prefer. I just want to get rid of pulseaudio on my firewall :-)

…

-- cheers, Holger

[h01ger]

On Fri, Feb 24, 2017 at 04:11:09AM -0800, Marek Marczykowski-Górecki wrote: Related to #2572.

indeed, though this is much easier to solve :)

Probably not only require changing "depends" to "recommends" but also putting pulseaudio module into separate subpackage.

I'm not sure this useful/needed, even though this is cleaner: it will just move some bits to another package, say qubes-gui-agent-audio (or -pulseaudio?) but if this weren't done, those files would just be part if qubes-gui-agent package, without being used, but without harm too. Or were you thinking of moving more bits out of the package? I'd also be happy to provide patches for whatever functionality you'd prefer. I just want to get rid of pulseaudio on my firewall :-)

…

-- cheers, Holger

[marmarek]

I'm not sure this useful/needed, even though this is cleaner: it will just move some bits to another package, say qubes-gui-agent-audio (or -pulseaudio?) but if this weren't done, those files would just be part if qubes-gui-agent package, without being used, but without harm too.

There is /etc/xdg/autostart/qubes-pulseaudio.desktop which would fail if pulseaudio is not there. Not a big problem, but far from clean solution. The best option is to move pulseaudio stuff (including that startup file and a script pointed by it) to a separate subpackage (is there any Debian naming convention for pulseaudio modules packages?), and have this subpackage depend on pulseaudio, preferably with explicit version, used to build the package, to avoid problems like #1927.

But then (actually in any case) we have a problem with upgrade path: recommended packages are not installed on upgrade, so if we want new (sub)package, it needs to be set at "depends". This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.
Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).

[marmarek]

I'm not sure this useful/needed, even though this is cleaner: it will just move some bits to another package, say qubes-gui-agent-audio (or -pulseaudio?) but if this weren't done, those files would just be part if qubes-gui-agent package, without being used, but without harm too.

There is /etc/xdg/autostart/qubes-pulseaudio.desktop which would fail if pulseaudio is not there. Not a big problem, but far from clean solution. The best option is to move pulseaudio stuff (including that startup file and a script pointed by it) to a separate subpackage (is there any Debian naming convention for pulseaudio modules packages?), and have this subpackage depend on pulseaudio, preferably with explicit version, used to build the package, to avoid problems like #1927.

But then (actually in any case) we have a problem with upgrade path: recommended packages are not installed on upgrade, so if we want new (sub)package, it needs to be set at "depends". This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.
Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).

[h01ger]

On Fri, Feb 24, 2017 at 05:40:19AM -0800, Marek Marczykowski-Górecki wrote: There is `/etc/xdg/autostart/qubes-pulseaudio.desktop` which would fail if pulseaudio is not there. Not a big problem, but far from clean solution. The best option is to move pulseaudio stuff (including that startup file and a script pointed by it) to a separate subpackage (is there any Debian naming convention for pulseaudio modules packages?), and have this subpackage depend on pulseaudio, preferably with explicit version, used to build the package, to avoid problems like #1927.

Seems all sensible and easily doable too. The Debian naming convention might lead to "pulseaudio-modules-qubes", though after looking at "apt-cache search pulseaudio" I'm not entirely sure…

But then (actually in any case) we have a problem with upgrade path: recommended packages are not installed on upgrade, so if we want new (sub)package, it needs to be set at "depends".

There are two ways out: a.) have a depends on that new audio package now (in the next release), and replace the depends with recommends in the next plus one release. (This also makes it mandatory that one cannot skip releases on upgrades, not sure whether this is the cases for Qubes.) b.) document in the release notes that templates will loose sound unless "$action is done" or three? c.) fix this using salt?

This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.

why do it break?

Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).

what's hard about #2572? Seems straightforward to me?!

…

-- cheers, Holger

[h01ger]

On Fri, Feb 24, 2017 at 05:40:19AM -0800, Marek Marczykowski-Górecki wrote: There is `/etc/xdg/autostart/qubes-pulseaudio.desktop` which would fail if pulseaudio is not there. Not a big problem, but far from clean solution. The best option is to move pulseaudio stuff (including that startup file and a script pointed by it) to a separate subpackage (is there any Debian naming convention for pulseaudio modules packages?), and have this subpackage depend on pulseaudio, preferably with explicit version, used to build the package, to avoid problems like #1927.

Seems all sensible and easily doable too. The Debian naming convention might lead to "pulseaudio-modules-qubes", though after looking at "apt-cache search pulseaudio" I'm not entirely sure…

But then (actually in any case) we have a problem with upgrade path: recommended packages are not installed on upgrade, so if we want new (sub)package, it needs to be set at "depends".

There are two ways out: a.) have a depends on that new audio package now (in the next release), and replace the depends with recommends in the next plus one release. (This also makes it mandatory that one cannot skip releases on upgrades, not sure whether this is the cases for Qubes.) b.) document in the release notes that templates will loose sound unless "$action is done" or three? c.) fix this using salt?

This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.

why do it break?

Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).

what's hard about #2572? Seems straightforward to me?!

…

-- cheers, Holger

[marmarek]

b.) document in the release notes that templates will loose sound unless
"$action is done"

I think this is ok. We do provide release-specific template upgrade instructions.

This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.
why do it break?

Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available.

Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).
what's hard about #2572? Seems straightforward to me?!

Yes, it's easy. Simply not done yet. Do you want to help? ;)

[marmarek]

b.) document in the release notes that templates will loose sound unless
"$action is done"

I think this is ok. We do provide release-specific template upgrade instructions.

This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build.
why do it break?

Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available.

Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly).
what's hard about #2572? Seems straightforward to me?!

Yes, it's easy. Simply not done yet. Do you want to help? ;)

[h01ger]

On Fri, Feb 24, 2017 at 06:33:53AM -0800, Marek Marczykowski-Górecki wrote: > b.) document in the release notes that templates will loose sound unless > "$action is done" I think this is ok. We do provide release-specific template upgrade instructions.

ok, cool (=agreed).

>> This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build. > why does it break? Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available.

then the whonix-workstation package should depend on qubes-gui-agent-pulseaudio :) and the whonix-gateway package should not. which seems much better to me than the current state, where there's pulseaudio and vlc installed on sys-whonix :/ ;) (and as a side note: while I understand why Whonix doesn't install recommends, I do think making "everything" a depends is the wrong solution for the problems inherited from that…)

>> Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly). > what's hard about #2572? Seems straightforward to me?! Yes, it's easy. Simply not done yet. Do you want to help? ;)

I guess so ;) It's just unclear what's really needs to be done for #2572 (which part needs fixing) and I only/mostly volunteer to help with the Debian side of things. (where "Debian" refers to dpkg/deb packages, not so much debian.org (only).)

…

-- cheers, Holger

[h01ger]

On Fri, Feb 24, 2017 at 06:33:53AM -0800, Marek Marczykowski-Górecki wrote: > b.) document in the release notes that templates will loose sound unless > "$action is done" I think this is ok. We do provide release-specific template upgrade instructions.

ok, cool (=agreed).

>> This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build. > why does it break? Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available.

then the whonix-workstation package should depend on qubes-gui-agent-pulseaudio :) and the whonix-gateway package should not. which seems much better to me than the current state, where there's pulseaudio and vlc installed on sys-whonix :/ ;) (and as a side note: while I understand why Whonix doesn't install recommends, I do think making "everything" a depends is the wrong solution for the problems inherited from that…)

>> Without #2572 we can't get rid of hard dependency on pulseaudio (either directly or indirectly). > what's hard about #2572? Seems straightforward to me?! Yes, it's easy. Simply not done yet. Do you want to help? ;)

I guess so ;) It's just unclear what's really needs to be done for #2572 (which part needs fixing) and I only/mostly volunteer to help with the Debian side of things. (where "Debian" refers to dpkg/deb packages, not so much debian.org (only).)

…

-- cheers, Holger

[marmarek]

It's just unclear what's really needs to be done for #2572 (which part needs fixing)

Because without #2572 we don't have easy way to introduce/alter dependencies. While release notes is one way of doing this, it doesn't scale well (we'd like to simplify upgrade process, not make it more complex). If we're going to place a point "manually install X, Y and Z" there, let make it the last time.
Also, not having #2572 make it impossible to have different packages set for different releases. This is why it is impossible to build Debian template for R3.1 right now (there was no qubes-mgmt-salt-vm-connector package in R3.1, but is on the list for R3.2).

As for Whonix - yes, but lets make it more explicit. If Whonix is not going to install qubes-vm-recommended, make it easier to check what it really means (and possible install subset of it by Whonix-specific dependency). Currently not installing recommended packages means you need inspect every package to see what really was missed - and periodically check if that list have changed.

As for using "depends" instead of "recommends" see #2572 (comment). In short: qubes-vm-recommended should "depend" on those recommended packages.

[marmarek]

It's just unclear what's really needs to be done for #2572 (which part needs fixing)

Because without #2572 we don't have easy way to introduce/alter dependencies. While release notes is one way of doing this, it doesn't scale well (we'd like to simplify upgrade process, not make it more complex). If we're going to place a point "manually install X, Y and Z" there, let make it the last time.
Also, not having #2572 make it impossible to have different packages set for different releases. This is why it is impossible to build Debian template for R3.1 right now (there was no qubes-mgmt-salt-vm-connector package in R3.1, but is on the list for R3.2).

As for Whonix - yes, but lets make it more explicit. If Whonix is not going to install qubes-vm-recommended, make it easier to check what it really means (and possible install subset of it by Whonix-specific dependency). Currently not installing recommended packages means you need inspect every package to see what really was missed - and periodically check if that list have changed.

As for using "depends" instead of "recommends" see #2572 (comment). In short: qubes-vm-recommended should "depend" on those recommended packages.

[adrelanos]

Holger Levsen:

>>> This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build. >> why does it break? > Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available. then the whonix-workstation package should depend on qubes-gui-agent-pulseaudio :) and the whonix-gateway package should not.

Yes.

which seems much better to me than the current state, where there's pulseaudio and vlc installed on sys-whonix :/ ;)

Yes, indeed!

(and as a side note: while I understand why Whonix doesn't install recommends, I do think making "everything" a depends is the wrong solution for the problems inherited from that…)

Your input on that are most welcome! Could you please start a discussion in a separate ticket or post?

[adrelanos]

Holger Levsen:

>>> This also applies to template build process - where even the easier option of making pulseaudio itself as recommended, will break the build. >> why does it break? > Because for example Whonix templates do not include "recommended" packages by default. This means Whonix Workstation will not have sound available. then the whonix-workstation package should depend on qubes-gui-agent-pulseaudio :) and the whonix-gateway package should not.

Yes.

which seems much better to me than the current state, where there's pulseaudio and vlc installed on sys-whonix :/ ;)

Yes, indeed!

(and as a side note: while I understand why Whonix doesn't install recommends, I do think making "everything" a depends is the wrong solution for the problems inherited from that…)

Your input on that are most welcome! Could you please start a discussion in a separate ticket or post?

[h01ger]

On Fri, Feb 24, 2017 at 09:17:23AM -0800, Patrick Schleizer wrote: Your input on that are most welcome! Could you please start a discussion in a separate ticket or post?

also as a qubes-issue on github?

…

-- cheers, Holger

[h01ger]

On Fri, Feb 24, 2017 at 09:17:23AM -0800, Patrick Schleizer wrote: Your input on that are most welcome! Could you please start a discussion in a separate ticket or post?

also as a qubes-issue on github?

…

-- cheers, Holger

[adrelanos]

Holger Levsen:

On Fri, Feb 24, 2017 at 09:17:23AM -0800, Patrick Schleizer wrote: > Your input on that are most welcome! Could you please start a discussion > in a separate ticket or post? also as a qubes-issue on github?

Yes. Anything works for me.

[adrelanos]

Holger Levsen:

On Fri, Feb 24, 2017 at 09:17:23AM -0800, Patrick Schleizer wrote: > Your input on that are most welcome! Could you please start a discussion > in a separate ticket or post? also as a qubes-issue on github?

Yes. Anything works for me.

[marmarek]

As for Recommends: in rpm packages: https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies
Especially, almost useless until "implement plugin: when package is removed then it will added to recommend exclude set and will not be pulled in when another package recommends it during installation" got implemented. Otherwise, updating qubes-gui-agent would re-install pulseaudio-qubes.

[marmarek]

As for Recommends: in rpm packages: https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies
Especially, almost useless until "implement plugin: when package is removed then it will added to recommend exclude set and will not be pulled in when another package recommends it during installation" got implemented. Otherwise, updating qubes-gui-agent would re-install pulseaudio-qubes.