From:
[email protected]
On Mon, Aug 16, 2004 at 03:03:35PM +0200, Robert Jordens wrote:
Hello!
[Mon, 16 Aug 2004] Jakob Bohm wrote:
Followup-For: Bug #248665
One more time for the obviously uncooperative maintainer:
1. Any program that *can* use jack but does not *need* to use
jack currently needs to link to libjack because the jack
development libraries do not provide any easy alternative.
There are quite a few easy alternatives to depending on libjack:
* dlopen()
* gstreamer0.8-jack
* libjackasyn (jacklaunch)
Do the jack headers provide ready-to-use declarations and macros
for use with dlopen? or does each maintainer of each
jack-compatible program have to do his or her own dlopen-adapted
copy of the jack headers?
Is gstreamer0.8-jack usable outside the GNOME environment?
Does libjackasyn provide full and uncompromising access to the
features of jack?
2. A rapidly growing number of Debian packages now fall into
this category because they either support jack as one of
several sound output alternatives, or link to a library (such
as arts) that does so.
arts? Any pointers that arts uses jack?
The libarts that was uploaded on Aug 14 with priority High
depends on libjack. This is what made me look at it at all, and
see how arrogant and uncooperative you have been about this bug.
I have also reported a bug against libarts asking that they stop
supporting libjack until this bug is fixed.
Judging from the other posts made to this bug in the past 3
days, I am not the only user to be angry about suddenly having
another daemon and associated libraries brought into my system.
BTW: Most of the "popular" programs that say they support JACK, are not suitable for serious use with JACK because they are not RT-safe. These programs can not fulfill the requirements that JACK poses.
You still don't get it: While the primary jack audience may
consist of hard core studio technicians and stage hands wanting
CD-mastering quality sound, there will undoubtedly be a large
number of users who will want to use jack at the same time as
they use lower-fidelity audio sources such as the error-beeps
from their office application or a beep when incoming mail
arrives while rehearsing.
To make this possible it is necessary for the ordinary, low-fi
audio applications and libraries (such as arts and esd) to be
able to send their output to jack. The obvious way of doing
that is to add jack as just another output library parallel to
alsa, oss, nas, esd and arts. To make that work, libjack must
behave like a good client library and allow itself to be linked
into such general purpose libraries and applications on a
just-in-case basis. This requirement includes the ability to
install libjack and libjack-dev without bringing in any other
overhead, such as jackd, lib1394, makedev (I use devfsd) etc.
Here is a hardware analogy: Studio and stage equipment
typically uses high quality balanced audio signals fed through
coaxial balanced plugs that are secured in place with rugged
screw-on fittings. However most studios and stages also carry
an assortment of converter cables that allow them to plug in
ordinary consumer grade equipment for both input and output.
This is used to play canned CD music (used to be cassette tapes)
in the breaks and while setting up or taking down the stage, for
listening to received demo tapes, recording funny telephone
conversations etc. Calling libjack from ordinary lo-fi
applications serves the same kind of purpose and libjack needs
to allow itself to be wired up to consumer grade audio software
without causing overloads or short-circuits in those fragile
plastic gadgets.
3. Installing jackd on a system that doesn't *need* to use jack
is a problem because future versions of libjack may start
jackd automatically (according to the jackd man page).
It is generally very bad for a library to Depend on any
non-library package.
Why? Seems to be common practice. Look through the package lists and search libfoo-bin packages, then chack whether their libfoo depends on them
either via libfoo-common or directly on libfoo-bin.
The first I found: libgnomeprint-bin
Yes, gnomeprint is a PITA for anyone using ghostscript (which is
just about everyone). I notice that the latest gs packages have
stopped depending on libgnomeprint, probably because of this.
4. This implies that libjack MUST NOT UNDER ANY CIRCUMSTANCES
Depend, Recommend, PreDepend, include within the package or
otherwise bring in jackd. Until this is fixed, libjack is NOT
fit for inclusion in ANY Debian release, and the RM should
move with maximum speed to get it out from sarge.
5. The excuse that libjack is not useful without jackd is simply
not true (see 1 and 2 above).
6. The excuse that jackd is not suid is not true, because
jackstart is suid which is just as bad.
Jackstart is clean. It only ever executes the jackd with the hardcoded checksum. And only if you already willingly applied the givecap patch to
your kernel.
That is not the point. It is suid because it actually does
something that the ordinary user is not permitted to do. The
admin of a recording-studio won't mind granting realtime
privileges to the sound software. The admin of an office
terminal server where KDE is linked to arts which is linked to
libjack which brings in jackstart probably does mind. The admin
of any kind of security-focused operation will not like having
any suid files brought in without pre-approval, source code
audits etc.
Applying the sadly needed kernel bugfixes for the capabilities
to actually work is not an invitation to install more suid
binaries. I have not had the time to check on the progress, but
a few months ago they were working on getting useable
capabilities into the stock kernel.
6. The excuse that some of the few packages that actually use
libjack in such a way that they are useless without jackd
might forget to depend on jackd is just that: A really lame
excuse for forcing jackd down everybody else's throat.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)