Removing hard dependencies on PulseAudio and splitting ports

I also build packages myself, without Pulseaudio (and some others probably). I don't really agree that it's fine to have it on by default because of something that actually happened and took quite some debugging to figure it out: when compiling SDL2 while Pulseaudio is installed, it'll give Pulseaudio preference over OSS (which IMO should always be the default on FreeBSD). Thus, on my system that had it installed but not configured there wouldn't be any sound.
If you're wondering why I compiled SDL2 outside of my poudriere build, that's because it was a source build used by UE4. Nothing special, but could happen to other people with other software as well.
For the packages I build I take a pragmatic minimalist approach, I disable what I really don't need or want (like Pulseaudio) and keep the rest at default config to prevent issues with other ports cropping up. If one day a port requires Pulseaudio, I'll either patch it out or just not install/use it.

I also have no idea why Pulseaudio is even useful really, is there software in ports that doesn't have sound if compiled without support for Pulseaudio? I haven't noticed any myself over several years.
 
Yesterday I updated 2 family PCs - both pulled in pulseaudio because of the newly introduced hard dependency by firefox-esr, for both PCs I got a call today because sound isn't working in firefox and some other programs because pulseaudio is spawned (without explicitly enabling/allowing it!) and doesn't work.
building from ports on those machines is completely out of question - these are old PCs (very first dual-core generation...) that would take hours or even days to build firefox and its dependencies; so I again had to use the dirty workaround of deleting /usr/local/bin/pulseaudio

So thinking about it again, this IMHO is a clear violation of POLA by breaking existing installations with default configuration.

If someone wants to use pulseaudio, one is always free to install/configure it and programs may use it (or need to be built with support) - but pulling it in and/or using it as default (which breaks existing configurations more often than not), let alone starting a daemon without enabling it via rc.conf should really be considered a regression and violation of POLA and be reported as a bug.
 
If someone wants to use pulseaudio, one is always free to install/configure it and programs may use it (or need to be built with support) - but pulling it in and/or using it as default (which breaks existing configurations more often than not), let alone starting a daemon without enabling it via rc.conf should really be considered a regression and violation of POLA and be reported as a bug.
Hear, hear!

It's sad Freebsd users are being saddled with this Linux crapware that is useless at best on Freebsd.
 
Hear, hear!

It's sad Freebsd users are being saddled with this Linux crapware that is useless at best on Freebsd.
I have PulseAudio pulled in as a dep when I compile my ports, and I don't care - nothing's broken, and it doesn't take up that much space, either. :p
 
Yesterday I updated 2 family PCs - both pulled in pulseaudio because of the newly introduced hard dependency by firefox-esr, for both PCs I got a call today because sound isn't working in firefox and some other programs because pulseaudio is spawned (without explicitly enabling/allowing it!) and doesn't work.
building from ports on those machines is completely out of question - these are old PCs (very first dual-core generation...) that would take hours or even days to build firefox and its dependencies; so I again had to use the dirty workaround of deleting /usr/local/bin/pulseaudio

So thinking about it again, this IMHO is a clear violation of POLA by breaking existing installations with default configuration.

If someone wants to use pulseaudio, one is always free to install/configure it and programs may use it (or need to be built with support) - but pulling it in and/or using it as default (which breaks existing configurations more often than not), let alone starting a daemon without enabling it via rc.conf should really be considered a regression and violation of POLA and be reported as a bug.
I basically agree on all points, but may I suggest replacing firefox-esr with just plain firefox? Here I am listening to a youtube video playing on firefox-90.0.1,2 with no special changes made to firefox, yet, in the konsole terminal on the right, you can see that pulseaudio is not running, due to the small edit I made in /usr/local/etc/pulse/client.conf which prevents pulseaudio from respawning, and, in all the cases I've tested so far, from ever starting itself in the first place.
Screenshot_20210722_115818.png
 
I basically agree on all points, but may I suggest replacing firefox-esr with just plain firefox?
Those two are very different beasts - www/firefox-esr is at version 78.12, while regular www/firefox is at 90.0.1... The esr version only gets pulled in as a dependency for some security ports (can't recall off the top of my head exactly which ones), and is not a fuctional drop-in replacement for regular version. Try installing and launching firefox-esr from Konsole, and you will see why.
 
Those two are very different beasts - www/firefox-esr is at version 78.12, while regular www/firefox is at 90.0.1... The esr version only gets pulled in as a dependency for some security ports (can't recall off the top of my head exactly which ones), and is not a fuctional drop-in replacement for regular version. Try launching firefox-esr from Konsole, and you will see why.
I don't have it installed and have no reason to install it. Maybe others do but I'm only offering a suggestion.
 
USE_TMPFS=all, it speeds up builds really nicely.

Thanks, I'm already with it. Also:

Code:
root@mowa219-gjp4-8570p:~ # zfs get canmount copperbowl/tmp copperbowl/var/tmp
NAME                PROPERTY  VALUE     SOURCE
copperbowl/tmp      canmount  off       local
copperbowl/var/tmp  canmount  on        default
root@mowa219-gjp4-8570p:~ # grep \/tmp /etc/fstab
tmpfs           /tmp                    tmpfs      rw,mode=01777              0     0
/tmp            /compat/ubuntu/tmp      nullfs     rw,late                    0     0
root@mowa219-gjp4-8570p:~ #
 
sko said:
Yesterday I updated 2 family PCs - both pulled in pulseaudio because of the newly introduced hard dependency by firefox-esr, for both PCs I got a call today because sound isn't working in firefox and some other programs because pulseaudio is spawned

FWIW, I run Firefox-esr built from ports with options Alse/Jack/Pulseaudio/Sndio unset ( make config says OSS is always available). Runs fine, no problems with sound. So Firefox-esr does work with OSS. However, building it from ports may take several hours on older hardware.
I don't know what this autospawn thing is good for. It reminds me of GW-BASIC times, someone once said his programs worked much better when he included a code line stating 'on error resume next'. Right...
 
may I suggest replacing firefox-esr with just plain firefox?

I've been using firefox-esr for several years now as my main browser - basically since they switched to full-retard-mode with their versioning and breaking stuff (plugins) every few days on the way. I don't need the absolute cutting-edge versions, but a reliable workhorse.
The ESR version is IMHO the much more sane and 'boring' variant which will just work (almost...), so I also install it on family/friends systems I maintain because it won't break stuff left and right whenever I come around to update those systems.
 
I too switched to Firefox-esr after the latest round of breakage from upstream. I've avoided any Pulseaudio troubles because I build my own packages with Poudriere, and have zapped most nonsense in my make.conf.
 
I've been using firefox-esr for several years now as my main browser - basically since they switched to full-retard-mode with their versioning and breaking stuff (plugins) every few days on the way. I don't need the absolute cutting-edge versions, but a reliable workhorse.
The ESR version is IMHO the much more sane and 'boring' variant which will just work (almost...), so I also install it on family/friends systems I maintain because it won't break stuff left and right whenever I come around to update those systems.
I did use ESR for quite awhile too, but then had some problems with it, the details of which I no longer recall. My approach to stability at present is to use quarterly packages, and only test upgrades on test installions until I find one satisfactory for my purposes. Different ways to skin slightly similar cats. Using packages instead of ports saves me a lot of compiler time, and I feel like it lends me a little more flexibility to try out different combinations without too many regrets. One major thing that has changed for me is that I no longer feel the same pressure I used to feel when it comes to keeping up with the cutting edges of the most recent developments.
 
All things considered, Firefox Quantum is better than pre-Quantum. www/firefox-esr is post-Quantum. Neither www/firefox-esr nor www/firefox is retarded.
I was referring to the illogical version numbering they switched to (omitting the first dot to get "higher" version numbers for marketing) and at the same time pushing out every miniscule patch as a new (minor) version every few days. This is just unbearable to maintain and had/has the overall quality of a beta- or rolling development release with constant breakage - nothing I want on production or family PCs that should "just work". But it seems this is nowadays the broadly accepted "linux way" of doing things...


edit:
regarding the original topic - I've just completed building a few things from ports and at least on my xfce4 desktop install, it seems there are 2 major dependencies of several packages that pull in pulseaudio: qt5-webengine and speech-dispatcher. after rebuilding those without pulseaudio (and jack + alsa) I was able to safely remove pulseaudio without pkg nuking half of the desktop applications. Actually I didn't even rebuild firefox-esr itself, because pulseaudio seems to be a 'third degree dependency' (through one/both of the aforementioned packages).

FTR: yes - one should never mix ports and packages. this was just an excercise to find out what actually pulls in pulseaudio on that system.
 
While I think it good to removing the hard dependency on PulseAudio (and others), it's not going to help much. In the end, most software are built for Linux, and not *BSD. The fact the software is even working on FreeBSD is merely a happen stance and or because some devs added some patches to get it to work. I am not saying Linux is better, as I do prefer FreeBSD. It's mostly that the Linux community started believing PulseAudio's devs in that Alsa is dead, even though PulseAudio needs Alsa to work. Now, OSS on Linux isn't like it is here; so there isn't any complaints that OSS is dead on the Linux side.

Either way we look at it, it's easy to see upstream isn't going to remove PulseAudio's dependency, and probably may also be resistant to supporting others.
 
Either way we look at it, it's easy to see upstream isn't going to remove PulseAudio's dependency, and probably may also be resistant to supporting others.
About programs that indeed require PulseAudio to work: yes. But they are not that many and I don't care about them. I'll even say it's nice to have PulseAudio available on FreeBSD so we can use them too.

What can and should be fixed, is the fact lots of software which doesn't require PulseAudio at all upstream (such as most of KDE software and qt5-webengine) is currently bound to it by our own packaging. That's not a thing to blame the Linux community for. Ironically, it's currently easier to get a fully featured PulseAudio-free desktop on Linux (Void Linux in my experience, probably true with a few other penguins too) than on FreeBSD.

https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-depend says:
When software has extra dependencies that provide extra features, the base dependencies listed in *_DEPENDS should include the extra dependencies that would benefit most users. The base dependencies should never be a "minimal" dependency set. The goal is not to include every dependency possible. Only include those that will benefit most people.
I agree about not going too minimal in enabling features but: does PulseAudio benefit most people? I don't think so. Opinions about it seem to fall in a range between "I don't care about it, it runs fine" and "I hate it". I still have to read someone telling how great it is and being thankful about its default installation.

I have mixed for years. Packages from latest.
We should think about finally founding that Beastie Mixing Heretics Society.
 
I have mixed for years. Packages from latest.
I did and do that too on several hosts/jails where I only need some other option for a single package (e.g. postgresql for postfix). I simply lock those packages, so pkg won't interfere with those ports and pkg lock -l gives me a list of packages I have to manually update via ports...
On a small scale thats perfectly maintainable, but I wouldn't want to do that for dependency nigthmares like a DE or browser.
 
Well for me the thing is that Pulseaudio was a piece of software originally written by Lennart Poettering (yup, the later systemd guy) in 2004 to solve some issues which some users back then on Linux might have had then.

Basically it replaced the esd thingy from Enlightenment. Then he later moved on to provide other gifts to the community and handed PA maintainer ship to somebode else. Poettering started Avahi and Systemd, at which he's still working on his quest to squeeze a whole operating system into an init system, also reinventing every wheel and then some he stumbles upon during his eternal quest of creeping featurism bloatware goodness.

It's a consumer level software project, let's call it that. It can do some things on software level which ALSA cannot do, however for most people ALSA would be more than enough. And professionals don't care about Pulseaudio, instead they to normally flock around JACK for good reasons.

Pulseaudio is a stranger on FreeBSD's land so to speak, an answer given to a Linux question and designed with mostly Linux on mind, as usual with Poettering's stuff. And therefore something most FreeBSD people really don't need, nor will it be ever a first class citizen. It just has this shitty tendency to replace ALSA interfaces in many pieces of software, which are sometimes also middleware infrastructure like BlueZ.

So more and more software has it nowadays as hard requirement - if you want audio, you need to have PA, otherwise you are lost.
 
for most people ALSA would be more than enough
Definitely.

So more and more software has it nowadays as hard requirement
I'd be interested in an list. I know there are some but haven't met many of them.

Quoting FreshPorts:
This port is required by:

[...]

for Libraries

accessibility/speech-dispatcher
audio/alsa-plugins
audio/bambootracker
audio/cava
audio/cli-visualizer
audio/drumstick
audio/fossmixer
audio/giada
audio/gstreamer1-plugins-pulse
audio/gtick
audio/myxer
audio/ncpamixer
audio/paman
audio/pamixer
audio/paprefs
audio/pavucontrol
audio/pavucontrol-qt
audio/pavumeter
audio/plasma5-plasma-pa
audio/psindustrializer
audio/pulseaudio-module-sndio
audio/pulseaudio-module-xrdp
audio/pulseaudio-qt
audio/pulseeffects
audio/py-pulsectl
audio/rtaudio
audio/soundtracker
audio/strawberry
audio/xfce4-pulseaudio-plugin
audio/zrythm
comms/cubicsdr
comms/deforaos-phone
comms/qsstv
comms/twpsk
deskutils/spice-gtk
deskutils/xfce4-volumed-pulse
devel/aws-sdk-cpp
devel/efl
emulators/dolphin-emu
games/retroarch
graphics/libprojectm
lang/squeak
multimedia/aegisub
multimedia/audacious-plugins
multimedia/avidemux
multimedia/avidemux-cli
multimedia/avidemux-plugins
multimedia/avidemux-qt5
multimedia/gmerlin
multimedia/obs-studio
multimedia/qmmp-qt5
multimedia/simplescreenrecorder
multimedia/snapcast
multimedia/webcamoid
multimedia/wf-recorder
net/gtk-vnc
net/guacamole-server
sysutils/cinnamon-settings-daemon
sysutils/gnome-control-center
sysutils/gnome-settings-daemon
x11/cinnamon-desktop
x11/gnome-shell
x11/polybar
x11/waybar
x11/wf-shell
x11-wm/e16
x11-wm/enlightenment
x11-wm/lxqt-panel
x11-wm/qtile


for Run

audio/pavumeter
... that's not that much.
 
Back
Top