Home | News | Download | Packages | Forum | Wiki | Github

MATE dependency to pulseaudio


Hello forum,
I’ve tested today for the first time Void Linux. I am looking for a systemd/pulse audio free distro.
I’ve installed Mate DE but it seems to depend on pulseaudio. As I tried to remove it, I got :

xbps-remove pulseaudio alsa-plugins-pulseaudio-1.1.6_1 mate-settings-daemon-1.20.1_1

mate-settings-daemon-1.20.1_1 (remove) breaks installed pkg `mate-1.20.0_1’

mate-settings-daemon-1.20.1_1 (remove) breaks installed pkg `mate-control-center-1.20.2_1’

I didn’t remove the mate package… :wink:
The mate-settings-daemon package seems to be the link between Mate and PA.
Is there a possibility for the package maintainer to compile it without PA ? Is Alsa supported by Mate ?

Thanks !

(maxice8 alter) #2

You can compile yourself with xbps-src, problably removing --enable-pulse from configure_args and alsa-plugins-pulseaudio from makedepends

could problably open a github issue too.


Thanks for the answer.
Compiling this way for myself would only benefit to me… and I guess a lot of people (Void users, I mean) would like to get rid of pulse in Mate too.
Is there a way to contact the responsible person for Mate packages ?
Thank you !


I just proposed the change: #14316 :wink:

EDIT: the proposal was refused, I’m sorry @fanfan :pensive:


Thank you for having proposed that change.
Very strange that the same distribution that wants to remove systemd does not at least give the freedom NOT to depend on pulse audio… is that so complicated ? I don’t know.


On the other hand, as @north1 pointed out, if a dependency gives you any trouble, you can still compile the package yourself using different options…
I guess many Void users have custom packages installed in their systems. :shushing_face:


We don’t want to remove systemd, the choice to drop systemd was for technical reasons only.
Mainly because systemd doesn’t support musl.

You have the freedom to build the packages however you like them, but changing the default because only one user doesn’t wan’t pulse audio won’t be happening.

Is that so complicated? No it isn’t.


Sidenote: apulse is a very useful project if you come across anything that’s a pulse-only build. I’ve found it useful for some Ubuntu targeted builds downloaded outside of void’s repos.

the freedom NOT to depend on pulse audio… is that so complicated ? I don’t know.

Complicated: yes, unfortunately.

It depends on the exact software – some have it as a runtime choice (likely best option, but then libpulse becomes mandatory in most implems), others have it as compilation time choice (this would require 2x the number of packages, one for alsa and one for pulse). No solution is perfect.


I ran into the same problem. There is no need to recompile mate-settings-daemon; just remove pulseaudio with xbps-install with the -f option. Of course this won’t work if you want pulseaudio on your system but from your posts I gauge you to be a person who doesn’t like Pulse. Anyhow that’s how I got around that issue.


Wouldn’t that reinstall it on every xbps-install -Suv?
There was some interesting idea about virtual packages that would allow one to change dependencies without recompilation, but I’m not sure if it’s implemented yet.

(Masato the Empty) #11

A virtual package like @eichorn suggests could overcome the issue he raises, as could a locally-built dummy package, which you could repolock so it never updates from Void repos. (Forceful removal is not a longterm solution and would mostly be useful for troubleshooting or temporarily removing a dependency in order to fill it with a different package)

Except it doesn’t necessarily sove the problem. It goes back to what @Veyrdite is referring to. To spell things out, if a program is linked against libpulse, and you don’t have libpulse, then when the program calls a function from libpulse, you’ll have a crash on your hands.

So the question becomes could you prevent the program from calling those? You may have a runtime option and that would make the answer yes.

But if that would be the case, you could think twice about expending the effort to remove it if you can prevent its use at runtime. There are reasons. It’s conceivable that its presence would cause other programs to use libpulse if found. Or maybe you think it uses undue space when that’s a constraint in your environment.

So, as veyrdite said, it depends.