stop 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 BTS refcard... 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. > --nO3oAMapP4dBpMZi > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > tags 265983 + wontfix > stop > > 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.