Bug#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2

[Stephan Jauernick]

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 - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Kind Regards,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150621/30030207/attachment-0001.sig>