pulseaudio: clean up

[ohanar]

This brings the package to be more inline with the bionic package, mainly disabling the daemon component as it isn't useful and instead relying on the bionic server.

Note: When XDG_RUNTIME_DIR isn't specified, pulseaudio calls a seeded rand to decide on a runtime directory. This means the glibc client won't find the server by default as the two libcs' rand are different.

[Maxython]

This brings the package to be more inline with the bionic package

What do you mean by this? Do you want to make the glibc-based package more compliant with the bionic-based package? Or do you want to make the glibc-based package work using the bionic-based package? In both cases, this destroys the independence of the glibc environment, which in turn reduces the capabilities of the glibc environment.

mainly disabling the daemon component as it isn't useful and instead relying on the bionic server

I plan to make pulseaudio-glibc work with android audio without the help of pulseaudio on bionic, but maybe I should disable deamon until it is implemented.

[ohanar]

This brings the package to be more inline with the bionic package

What do you mean by this? Do you want to make the glibc-based package more compliant with the bionic-based package? Or do you want to make the glibc-based package work using the bionic-based package?

I mean the actual package descriptor (i.e. the contents of build.sh) is brought closer to the bionic package descriptor. This makes it easier to port over improvements made to the bionic package to the glibc package.

Also independence of glibc is not the same as reduction in capabilities. As it stands right now, the only way to functionally use the glibc pulseaudio client is by using the bionic daemon, and the changes made here make it easier for a user to use that configuration. Sure, it isn't independent, but I'd argue that is an increase in capabilities of the glibc client, as having a non-functional daemon is more confusing to user and not providing any value to the user.

[Maxython]

I mean the actual package descriptor (i.e. the contents of build.sh) is brought closer to the bionic package descriptor. This makes it easier to port over improvements made to the bionic package to the glibc package.

What improvements from the bionic package would you like to add to the glibc package? According to your PR, the main change is disabling deamon (that I approve of this), setting bionic-based pulseaudio to be used by default (which is a pretty bad idea to do) and disabling a lot of dependencies on pulseaudio (which is also highly questionable).

Also independence of glibc is not the same as reduction in capabilities.

Just for understanding, by the word glibc independence I mean that the glibc environment could work independently using only its components (binaries or libraries) from its environment. Without following this rule, in a certain case something can break due to a conflict between the glibc environment and the bionic environment (this is one example).

As it stands right now, the only way to functionally use the glibc pulseaudio client is by using the bionic daemon, and the changes made here make it easier for a user to use that configuration. Sure, it isn't independent, but I'd argue that is an increase in capabilities of the glibc client, as having a non-functional daemon is more confusing to user and not providing any value to the user.

You are right. But making pulseaudio-glibc work directly with bionic-based pulseaudio is also wrong. In certain cases (mostly when LD_PRELOAD is configured for the glibc environment) bionic-based pulseaudio simply won't start.

In conclusion, I want to say the following: your main ideas are clear to me (and I approve of them), but I don't like your change in PR because of "brought closer to the bionic package descriptor" because I don't understand the reasons for this. Therefore, perhaps I will make PR instead of your PR, with the following changes:

• Disable daemon
• Add a warning message during package installation that pulseaudio-glibc only works with bionic-based pulseaudio
• And maybe I'll add a special script to easily run pulseaudio based on bionic for pulseaudio-glibc

[ohanar]

What improvements from the bionic package would you like to add to the glibc package? According to your PR, the main change is disabling deamon (that I approve of this), setting bionic-based pulseaudio to be used by default (which is a pretty bad idea to do) and disabling a lot of dependencies on pulseaudio (which is also highly questionable).

Nothing in particular at the moment, it is more future looking. All the dependencies I removed are daemon-only dependencies, so if you disable the daemon, then they become false dependencies.

Just for understanding, by the word glibc independence I mean that the glibc environment could work independently using only its components (binaries or libraries) from its environment. Without following this rule, in a certain case something can break due to a conflict between the glibc environment and the bionic environment (this is one example).

I understand this perfectly well (I have dealt with plenty of symbol conflicts in my day job), but at the same time I view that mindset as an instance of "perfect is the enemy of good". Pulseaudio works over a server/client protocol, so using a glibc client is perfectly compatible with a bionic daemon as they are independent processes (and in fact can be run on entirely different machines, something I did back in college ~15 years ago). The good, which is far as I know, this being he only way to be able to actually hear audio played through the glibc pulseaudio client at the moment, outweighs the perfect on a non-existent working glibc daemon in my mind.

You are right. But making pulseaudio-glibc work directly with bionic-based pulseaudio is also wrong. In certain cases (mostly when LD_PRELOAD is configured for the glibc environment) bionic-based pulseaudio simply won't start.

Admittedly I haven't had LD_PRELOAD set when running things (as a grun shell doesn't seem to set it by default), and indeed that does break the autostart.

[Maxython]

Thanks for the PR