I'm a bit dissappointed by the reply you got back to this suggestion, so I'm adding some thoughts concerning your idea.
On Saturday, June 23, 2012 15:54:07, Michael Schmitt wrote: > Hi folks, > > I guess shipping both versions with wheezy is not a viable option? At > least I think that it would make sense. Disclaimer in the readme, > explanation of the situation, if a major security exploit does surface > (a mumble-client-crash is not a major security risk imho), remove that > second version (if there is no somewhat easy fix at that time). Call the > package mumble-client-buggy that conflicts with the "normal" client and > I guess all users can decide on their own if they want to be safe or > actually talk to other people. What you're proposing concerning adding a 'mumble-client-buggy' could technically be done /in theory/ and even occasionally has been in other packages; the packages 'gobby' and 'gobby-0.5' are an example. If you look these binary packages up, you'll see they have two different source packages too -- 'gobby' and 'gobby-infinote'. The reason these exist is that the two versions of the software are incompatable by design, and 'upstream' still offers both versions. Debian Wheezy is extremely close to being frozen in preparation for releasing the next version of Debian Stable -- a "buggy" package destined for the "stable" release would have to be justfied and would likely be rejected by the ftpmasters after upload if it couldn't be. Plus it sounds like there are several other issues to handle. These types of decisions are generally up to the maintainer of the package as to how to proceed. It's clear the maintainer for mumble is frustrated right now, because (IMHO) there isn't a clear path as to how to proceed here. Several options are possible, but nothing seems to exactly fit -- removing the CELT codec breaks communication with popular older mumble/murmur servers, leaving the codec in has security and support implications, making both packages available would require going through the NEW queue at the last minute and would additionally risk being rejected. Because of all these sticky problems, without a clear path to proceed if I were personally in the maintainer's shoes I'd probably take the "do nothing" option and release the current "348" version that has the libcelt0-0 codec that has issues but retains compatability with older popular mumble servers. I wouldn't /like/ this option though, because I'd have to support it for two years, and upstream isn't supporting the buggy CELT 0.7.1 codec at all. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
