Bug#265983: libarts1: Do not depend on the jack packages they bring in too much crap
Note 1: If this causes the bug to reopen, just reclose it.
Note 2: The stop line above is just there in a vane attempt to
avoid affecting the bug status, but I forgot where I put the
Note 3: Since sarge is now much closer than it was when the bug
was filed, changing libarts (again) at this stage is probably
worse than undoing a risky move during the early phase of the
freeze. So you may downgrade all the way to wishlist now.
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> tags 265983 + wontfix
> 1. It pulls in less than 1MB of installed packages that you might not
> already have installed.
> 2. Many things in Debian haven't reached "1.0" yet. I guess jack is
> relatively new vs the stone age... It has been in Debian since
> Dec 23 2001 and has been around since ~ Apr 2001 previously being
> called AES/LAAGA (aiui). 3.5 years isn't that new. Perhaps you don't
> like ALSA either since it is relatively new (over 6 years old) and
> just reached 1.0 in the past ~ 8mo. :)
> 3. I don't see a problem with #248665.
> BTW arts will most likely be going away when KDE 4 is released in a
> few years. It is more than a notification system it is closer to a
> combination of esd and gstreamer.
Just to clarify:
1. The complaint is not that Jack takes up a few MB on the disk.
it is more the fact that bringing in Jack adds to the overall
system complexity, including the introduction of yet another
"daemon" (actually suid) package that I did not ask for.
2. Of cause Jack is not new. The dependency from ARTS to Jack
is new, and thus the inclusion of Jack in a lot of systems
that previously ran without it. Historically Jack was
installed almost exclusively by audiophiles, musicians etc.
3. #248655 is a long standing bug (originally not from me) that
the libjack maintainer has (unilaterally) decided that any
user who installs libjack (for any reason) can be presumed to
consent to the installation of the jackd package, the use of
certain kernel security facilities to "speed up" Jack if those
security facilities happen to be present, etc.
The bug log for #248655 shows that the libjack maintainer is
extremely arrogant about the importance of his own package and
seems unable to wrap his head around the possibility that the
dependency system may cause libjack to be installed by people
who never asked for it. Given this kind of stubbornness I
would recommend that libjack dependencies be avoided like the
plague. In one of the responses he sent to me on that bug he
even insisted that having things like KDE/ARTS depending on
Jack is a "misuse" of the high and mighty Jack.
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.