On Friday, July 20, 2012 23:22:33, Steve Langasek wrote: > On Sat, Jul 21, 2012 at 07:34:36AM +0930, Ron wrote: > > > > I see that Philipp asked you to undo the change and you have > > > > declined, as is indeed your prerogative. I assume that that's > > > > because you agree with Ron's reasoning, but without seeing Ron's > > > > reasoning, it is difficult to understand your decision. > > > > > > It is both that I agree with Ron's reasoning and that the linkage > > > against libroar in the first place was a quite bad experience and I had > > > already considered dropping it again (as can be seen in below > > > conversation, where at first I don't even realize that Ron's reasoning > > > is Celt removal but I assumed it was just libroar being unneeded and > > > having annoyingly strong dependencies). > > > > This actually wasn't just about celt. > > > > Bastian Blank (among quite a few others over many months) was also, uh, > > "upset" shall we say, about roar dragging DECnet in to the debian > > installer. Both Philipp and Patrick were quite clear, and repeatedly > > insistent, about voicing their opinion that they would rather have roar > > removed than fix these things in roar itself. > > I can vouch for the horribleness of this library stack. > > https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/883602 > > So we have: > > - a package that mangles mac addresses of interfaces as soon as it's > installed, > - recommended by a library, > - that had to be NMUed *more than once* to get rid of this dependency > (bug #608807, bug #655740), > - and is packaged as a native package with a binary package name that > doesn't follow shared library naming conventions, > - and this is all a dependency of an *audio* library! > > So thank you, Ron, for your efforts in trying to stop this madness from > being pulled in on our users systems. My thanks likewise, because that sounds like an enormous mess. > > Trying to conflate this with the mumble issue however is Not Helpful. > > I agree. I don't see any reason the TC should be revisiting maintainers' > decisions to drop celt 0.7.1 as a dependency; the mumble case is a very > particular issue related to the exact manner in which the server is > repeating the audio to all clients, and I don't see any reason to suspect > this would be an issue for the other packages that have dropped celt > support. Roaraudio was being looked into because we were discussing reintroducing celt, due to a combination of a naive but well-meant suggestion on my part itself due to to a lack of relevant information about why the dependency on celt was being removed from the mumble package. The way this all started in the first place was that I couldn't figure out why celt was being removed, because the bug report on the mumble package about that [1] was wholely uninformative about all of the numerous issues the celt 0.7.1 library has that we've now discussed at length. [Dead upstream, desire to remove the package from the upstream authors, ancient version, bitstream incompatability with each release, etc.] I tried to search for bug entries in the BTS on the celt library itself, but I wasn't able to find any, possibly because the package had been removed. In the original bug report [2] that resulted in a communication breakdown and a referral the TC, the discussion on the celt library surrounded only a possible crasher bug, which left bug reporters confused as to why that issue couldn't be handled another way such as reporting the matter upstream -- because we didn't know upstream was dead. Because of all this, reintroducing the celt library seemed to look like a reasonable solution. And once reintroduced, it was reasonable to look at the other packages that had depended on it -- this was my suggestion. I tried to find which packages were affected by the removal and found [3], to which it seemed roaraudio had been most impacted. The previous maintainer for roaraudio complained about loss of a major feature due to celt removal [4] and additionally seems to have quit Debian over some kind of conflict related to this very issue. [5] These latter two things seemed to imply that removing use of celt from roaraudio might have been wrong. At least an initial examination into roaraudio seemed reasonable, in my humble opinion. I don't think we went too far down that path. So anyway -- hopefully this clears up how this issue got conflated. It's something along the lines of "the road to hell is paved with good intentions." [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674650 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674634#5 [5] https://lists.debian.org/debian-devel/2012/06/msg00983.html [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674634#10 -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.