On Fri, 2008-05-02 at 10:22 +0100, Daniel James wrote: > Hi Paul W, > > > someone needs to get in contact with upstream and educate them about > > the evilness of embedded code copies. > > I don't think that's a very helpful approach. The Ardour team are > already aware of Debian's reservations about the embedded libraries.
You can say that again. Yes, we'd love to avoid the security issues, increased memory overhead, extra maintainance costs and overall redundancy of embedded libraries, but we're not going to. > Consider that the Ardour team do not want to be receiving bug reports > for years into the future from Debian, Ubuntu and other Debian > derivative distro users about problems which are not present in their > own copies of the libraries. There is really one library to which this specific issue applies, and that is libsndfile. The reason that this is included in the Ardour code tree and installed with the executables is that its author has still not released a version containing the fixes that we need, approximately 18 months after he said he would do so. Calling them "fixes" may be misleading. They are small changes in semantics. As soon as Erik does release this, we will remove libsndfile from our tree. Until that time, the libsndfile that comes with Ardour cannot be considered equivalent to the one built from "upstream" sources. However, the historical reasons are more pressing for us. Whatever debian (or any other distribution) maintainers may tell us, we know one thing for sure: there are plenty of users who will end up building Ardour with a different C++ compiler or even just sufficiently different compiler flags than were used to build the C++ libraries that Ardour depends on. The abject failure of the gcc project to maintain a stable ABI for C++ caused us to spend hundreds of hours of wasted time tracking down issues caused by these compiler mismatches. Our solution was to get rid of them for once and for all, by putting all the C++ libraries that Ardour uses (and that do not come with the compiler) into the source tree. As a nod toward distributions like Debian, we added the SYSLIBS compile time option, but using it means that we will not provide any support to the user. Yes, we've heard for years that "there will never be a compiler mismatch, the user will always have the same g++ as was used to build libfoobar". Problem is, not a month goes by when this is disproved. We are *not* going to waste our time figuring out why the system build of libfoobar is breaking ardour when we already know that the build done as part of ardour's own build process works just fine (and I am not talking about code changes to the library, just the build processes). And its not just debian. Gentoo has had this problem recently, where their maintainer messed up their ebuild (using SYSLIBS) to produce a crash-on-startup version of ardour. Who do you think got to clean that up, us or the "packager" ? --p -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
