kmines needs pulseaudio. Why?
 

Not that matters much, but if I remove pulseaudio kmines doesn't start:
I can start it typing "apulse kmines" though.

Just curious: I never heard a sound running kmines.

This is on Slint, but with the genuine KDE Slackware packages.

Isn't it fascinating that near riots ensued regarding systemd yet pulseaudio is far more insidious. OK I get it. At least PA does fill a need for some folks but I don't get why nobody has created the equivalent of eudev to handle such management as an option rather than stuffed down everyone's gullet as an enforced requirement.

maybe some of the developers think "everyone else is doing it, why wouldn't you want it?".

My guess is it is probably lumped in from something linked with KDE. If you look at the ldd, this links to a lot of libraries, especially sound-related libraries like libsndfile, libFLAC, libvorbisenc (really? vorbis encoding?), libvorbis, libogg, and maybe a few others I missed.

On a system using pulseaudio, kmines requires libkdegames which requires libphonon which requires libpulse.

Just removing pulseaudio while leaving libraries linked to it results in a broken system, really. So kmines failing to start is in no way the fault of pulseaudio. If you run the script in extra/pure-alsa-system to remove it properly and make sure that nothing is still linked to it, then kmines starts up and runs fine.

Thanks Patrick for the explanation. Actually I removed PulseAudio just to be sure which web browsers are linked to it. It appears that Chromium is (I use the one from Eric, thanks to him) but not Seamonkey. This made me realize than then kmines ceased to work. But I have no intention to remove PulseAudio for good.

That is not the way to do it, since if the web browser links to a library which happens to link to pulseaudio, you will get a false positive, which is what happened with kmines. 'objdump -p' will tell you what a particular binary requires to be linked with (look for lines beginning "NEEDED").

For what it is worth, google chrome (not chromium, I don't have that installed) is not linked with pulseaudio.

Edit: Out of interest I downloaded the version of chromium you have and that build does have a dependency on pulseaudio. Interestingly firefox's in house build does not have a linker dependency on pulseaudio, but I think I am right that recent versions will not in fact play sound on a pure alsa installation.

On Plasma5:
Here it is not linking to PA.

Well, objdump -p just gives the direct links, so I use ldd to get all of them in one command. As an aside, if kmines is started one can get its pid and type 'lsof -p <pid>' to list all linked shared libraries. Example:PS Building a packages dependencies tree using 'objdump -p' recursively is left to the reader as an exercise. Alas it will work only for the binaries, not for the scripts in Python, Perl, whatever.

I should make it clear and once again thank Patrick for his wisdom and judgment not to mention his hard work. Above I was specifically referring to Mozilla Firefox which really bothers me probably more than it should but I can't stop wondering what they (think they) gain by disabling ALSA-only since it is obviously still active and supported since PA is a manager NOT a sound server. Especially since Firefox also obviously works fine without PA what do they gain or hope to achieve? It reminds me of when MS bought out Skype, forced an update locking out the use of certain libraries, but hackers discovered that if one simply renamed the app to the next version, presenting a phony ID in effect, Skype worked just fine with all the old libraries. It's like running a race where not only do you train for stamina and speed, but also effective means of tripping up other runners. It may be valuable in the modern economic world but it is also just ugly.

In my case I am using the patch patterns from Current on 14.2 in order to get ALSA-only working for me now before the next version release. I am as always greatly indebted to Patrick for all his efforts to keep Slackware as Vanilla and flexible as possible. I have donated some in past years and I am feeling the need to do so again. I just discovered this week that quitting PayPal doesn't actually quit it so as soon as I talk to an officer at my bank to better understand what relationship still remains with PayPal my thanks will once again not be mere words.

Mozilla OTOH, will likely never see another penny from me.

Best guess is there are probably no developers running a pure-alsa system that want to maintain the alsa integration. Sure, PA needs a sound server, but programs don't need to directly interact with the sound server as they can obviously interact with a sound manager. As we've seen on the forum over the years, having a sound manager can greatly benefit some setups (but obviously hinders other setups).

Sure, the code for alsa-only might work now, but if it's not being maintained, who knows how long that will last, either due to a change from alsa (unlikely) or a major change in how the browser handles audio.

Plus, there's very few pure-alsa systems available nowadays, so the incentive for them to ensure they work properly is minimal. The gain for the developers seems obvious to me, even if it is frustrating for some users.

I think mozilla is just special software, they have had major changes lately which have broken many use cases. Most programs I use are fine with only alsa and no pulseaudio.

While I understand I am in a small niche and don't represent the bulk of Linux users and also that down the road changes may prove disabling alsa-only was prudent, for now it is simply and essentially one single "checkbox" as far as I know and I don't see how that option currently hinders firefox development. Do you?

Why should they enable something that could be broken? These questions on whether they should or should not enable it can be asked both ways. None really provide a great answer. This is just how Mozilla decided to support their official builds, by not enabling a configuration option that they don't know the current status of.

Actually I rather imagine it is Mozilla's thinking "Ah good! Now, with PA, Linux sound is somebody elses problem".

I recall being pleased, way back in the day, when I no longer had to manually setup, for example, a modem BUT I wouldn't have been at all happy if my Up/Down decreased by 20% because of the PNP autoconfigure. Too bad Jack didn't take the reins. It's orders of magnitude better than PA.

Probably... this goes back to the UNIX philosophy. Do one thing and do it well. This will obviously open up a can of worms, but why not leave the audio problems to someone else when they can focus on the browser and keeping it secure? Yes, I'm aware there's probably thousands of examples where this isn't the case and programs support 30 different sound managers/servers, but there are probably thousands of examples where developers have done the exact same thing as Mozilla.

Like it or not, pulseaudio is the primary sound manager in Linux. Almost all distros use that as their default sound manager, so from Mozilla's standpoint, it makes sense to go to the highest common denominator, not to enable the few obscure situations when someone decides to not use pulseaudio and apply that manpower elsewhere than testing someone's obscure pulseaudio-less system. Does this work for everyone? Obviously not, but for the vast majority of people, it works fine.

At least you're running a distro where the Firefox package is provided enabling alsa and it is relatively easy to build your own if a version you want is not provided by Pat.

Nothing but respect, but this might not be the best argument for Slackers. (as in the other package that goes unnamed)

I should have marked this thread as [SOLVED] after post #9, this could have maybe avoided following off-topic posts. This is fixed now.

I wasn't trying to cater to Slackers, but what Mozilla's thought process might be. We've seen this same situation for programs that require systemd, some drop support for non-systemd distros. It may not be desired by people who don't like it, but when you want to focus your resources on other aspects of the program, you might need to cut support for less common systems out there. It sucks, but it's reality.