Another idea for comments (Len Ovens)/Pulseaudio removal

[Len Ovens]

On Tue, July 31, 2012 10:49 am, Luke Kuhn wrote:
>
> I always remove Pulseaudio because I have never been able to get full
> performance in Kdenlive with it running (choppy with AVCHD based files). I
> have Jack if I need a mixer, and my small machines (both netbooks and all
> my Pentium III /low resource experiments) have video playback issues with
> pulseaudio using so much CPU. I've played with Pulse, never been able to
> get it to cooperate with these demands.
>
> About "unremovable packages" remember that there is no way to make any
> package unremovable to anyone with root/sudo access. The binary can have

Whoa, I wasn't suggesting making any package unremovable. It was:
>> Choice is king. Making a package non-removable is not something I want
>> to start doing.

To make it any more clear I don't see making something unremovable as a
solution to any problem. I don't know how (depends can make harder I
guess) and I don't really want to learn. What I do want to do is make it
easier to remove a meta without causing problems, but even better make it
possible not to install an unwanted meta in the first place and possible
to install later if needed. Possible to remove a single package even if it
was installed as part of a meta package.

I think that covers it... but it may not.

> its permissions changed to disallow running or simply be deleted, then the
> package pinned to prevent reinstallation. In fact, I used to turn
> Pulseaudio on and off that way (to stop it from respawning if killed)

I may use that in some way.

> until I found a volume control that worked. That was volti, thanks to
> another contributor on this list. Of course, someone who understands video
> editing but not the Linux file system would be stopped by this if APT
> won't let you pull the package without ripping out a lot of other stuff.

I want to prevent that too. I would like the user to be able to just
remove pulse if they want to. I like flexibility.

>
> Making too many other packages depend on Pulseaudio is a bad idea. Things
> focussed on pulseaudio obviously would, but such dependancy on, say, an
> audio editor, would have the effect of making that package incompatable
> with Kdenlive if AVCHD files are to be used, and with all video players,
> even Flash, on low resource boxes.

I don't know that we would have to even make gstreamer depend on it
because it will work direct to ALSA. In fact I can't think of anything
that would have to have pulse except a pulse plugin/module package. Pulse
is default because someone new to audio may not expect not to be able to
play more than one stream at a time, for example listen to oggs and check
out a video at the same time. This is not normal for audio production of
coarse.
>
> Not such a big deal with a meta-you can install the meta, then remove it
> and anything it brought in you want to remove. Still, that adds complexity
> that can stop end users dead in their tracks and for that reason alone
> should be avoided. Dedicated machines are just one reason for this, the
> fact that everyone's workflow is different is another.

So are you saying Studio should not offer the installing user a choice of
which workflows to install? Or that we should not install all workflows
and then let the user remove some? I don't think we can offer the first
without the user being able to unload a meta. But the fewer a machine
starts off with the better IMO.


-- 
Len Ovens
www.OvenWerks.net