Bob Ham wrote:
Sorry that this took me so long!
> On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote:
What would guarantee that a JACK controller app would always get first
priority (or be a "root dependency")? The controller app itself via an
init flag? The user (bad idea IMHO)?
Anyway I'm not sure if this topic is going anywhere in the foreseeable
future. I fully agree that priorities/dependencies is a good idea, though.
>>>>> User interface standard
I didn't realize you meant a recommendation and not some UI protocol.
(I'm not too familiar with GNOME.) Sure, but why should it be
LASH-centric? Why not write an official linuxaudio.org HIG?
Another question is how needed/desired something like this actually is.
(Does the VST SDK come with a HIG document?)
>>>>> Automatic client installation
If we are to restrict this topic to strictly providing hooks for
existing package managers, then we might be able to stay out of trouble.
Otherwise I suggest you go ask about it on #debian. :)
>> Abstracting package management for distros is an insanely huge task
All I have to say is good luck. :)
>> Using autopackage is out of the question,
The point isn't to safeguard the poor packagers from grey hair, although
to a certain extent that's also a factor. What I'm worried about is how
on earth will a rogue package manager, working irrespective of the
distro's own managing system, benefit the users in the long run?
Sure, you will be able to quickly install externally provided packages
via some nifty tool, just like you can quickly unpack binary tarballs in
your root. And when the distro's package manager pulls a straw up its
nose due to broken lib dependencies and whatnot, I guess the users won't
feel too good afterall.
>> If a session manager would take on package management like this -- which it
I apologize if this sounds like circular logic, but it is: A package
manager is what you use for managing packages, and when managing
packages what you should use is a package manager. Linux != Windows.
>> -- it would have to work absolutely
An external package installation system would by and far not work
"normally" at all on many systems.
>> I wouldn't want autopackage messing around with my box -- I want
That's as far as I'd be prepared to go. If LASH would notice that I
didn't have $PROGRAM installed, and it would tell me my distro's package
name for $PROGRAM, I'd be very happy. I would _possibly_ even be willing
to click on a link saying, "Click here to install $PROGRAM using
And even that "simple" feature would require LASH to ship with an
up-to-date matrix of program names matched against all distros'
corresponding package names...
>> Considering how you've been defending LASH from features that you deem outside
I would strongly argue that managing packages is way beyond the concept
of session loading. But I don't feel that we should really be wasting
much time on this subject at this point anymore.
>>>>> Redesign client/server communication
Can you clarify whether you mean the LASH client or server interface
when you say that they would communicate similar information?
Linux-audio-dev mailing list