Hi Adrian, On Sun, Jun 21, 2015 at 10:29:21AM +0200, John Paul Adrian Glaubitz wrote: > On 06/21/2015 02:31 AM, Jonas Smedegaard wrote: > >> Even just checking for the existence of dnet-common or similar > >> would probably be enough. > > > > As I understand it, these are the issues raised here: > > You understand incorrectly then. > > > a) libdnet is unmaintained and thus potentially dangerous to link > > against > > > > b) dnet-common commonly (or always by default?) cause whole system > > to hang > > *Not* dnet-common, _libdnet_, seriously, read what I wrote! >
libdnet is just a wrapper. You are jumping to unconfirmed conclusions here. > > I disagree that any of above are bugs in cmus. > > Again, you are not reading what I wrote. Please leave the discussion > if you refuse to do so! Alessio Teglia, one of the cmus maintainers > himself said "Please file a bug report against cmus and ask for > libroar2 to be demoted from Recommends to Suggests". > The roar and pulse dependencies are now only installed per suggests. You will probably still get the unconfirmed bug if you use the --install-suggests switch for apt. As that will pullin the stuff. Maybe the proper way might have been to put them into seperate plugin binary packages like it is done for cmus-plugin-ffmpeg? If not then you will encounter the funny problem that cmus might not start anymore if you don't have libroar or libpulse installed. In my test it produced a considerable hang on the first launch while it tried to find a audio output. Btw. I could neither reproduce your bug on a debian jessie -> testing upgrade. You did a great job there. 1. Threatening with the Technical Commitee Sledgehammer against cmus 2. Possible usability problems for cmus 3. Doing nothing to fix or locate the original problem The propper course of action, regardless if dnprogs is unmaintained or not, would have been to debugg the problem. After that to clearly isolate the component inside roaraudio/dnet/cmus/whatever and then file a appropriate bug. If this would then be a request to drop the linkage or a bugfix against one of the componts doesn't matter. You could have simply opened a bugrequest against roaraudio to drop the decnet dependency and then if nothing happens consulted the TC. If you would have read the two bugrequests you have linked then you would find out that these were either already answered with a description and a note that dnet-common won't be a recommended dep anymore or that there are next to no informations at all. But neither are you fixing the problem at the right place nor is unclear if you are fixing it at all. What is if its a legitimate bug? Now others will stumble upon it and have to work it out themselves. While it could have been debugged without much invested time on your side. If this is how debian works nowdays I am unsure if i want to continue using it. Why do i even care? Sorry if you see it as insultive, but it seems to me that you fail to see reason and are just mindlessly focussed on getting rid of roaraudio via the wrong methods and actions. Thanks. > Fy fæn, Jonas. Les hva folk skrev før to du svarer eposten! > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Kind Regards, Stephan
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
