> This is different understanding between us. > > I'm working at a distro vendor, and as a responsible person for > distribution packages, the first thought is maintainability. So far we agree. > For that purpase, I prefer very much a shared library approach because > I know the hell of vice of copying codes. Copying code works well if > it's 100% safe and mature code, which requires no longer updates and > fixes. But a code being developed shouldn't be copied. Not sure I agree here. Do you really want to depend on libspeex "blindly" not knowing what changes I make (while the code is evolving). Code copying is not necessarily bad. After all, that what the kernel does with the ALSA drivers -- sync up every once and then. > That is, the only criteria for inclusion is whether the code is well > tested and no more fix/update is needed. In this case, whether > resample code has to be further sync'ed with speex codebase or not. > If it should be kept synced, then shlib approach is clearly better. > Otherwise we have to take care of two places at the same time. I guess my main question would be: are you willing to make libspeex a *mandatory* dependency? If not, please include a copy of the resampler. >From now on, there's no way alsa-lib should ever be built with linear interpolation resampling unless the user specifically configures it with --enable-awful-audio-mutilation-code or something like that. > Or, in other words: the sound quality could be a matter of taste, but > a security fix can't be so :) I don't see much security issues here. The code is really simple and (unless I've done something really obviously stupid -- which I don't think I have) you can easily show that there's no buffer overflow possible. Jean-Marc _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
