Re: Ardour still not present in testing
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
Reply to: