Keep in mind that we build on Windows, so much of the code in our third_party directory is there because we need that code on Windows. There are a number of configure time flags to switch between the third_party and system versions of libraries like zlib, libevent etc.
No one is decrying your use of a third_party directory. Mozilla does this too.
However, it's a bit harder to use system libraries than you make it seem. For example, looking through spot's src.rpm, I see no less than 7 patches to hardcode stuff to use system libs. Take this commit for example. Pretty much every file references ../third_party/icu, but when you look for the actual directory, it isn't there!
Having said that we do have a number of forks. Here's an unrepresentative selection of them covering some of the reasons: libevent: we needed bug fixes and we needed to be able to run on systems which didn't have them. icu: we need a more recent version than was even provided on Karmic.These are the distributors problem. Either they configure --with-system-libevent and get the libevent maintainer to update their part or build and ship with the library.
libjingle: upstream appears to be unmaintained.Several have mentioned Google is the upstream maintainer. Either whip the talk guys into shape or get commit access to their tree.
sqlite: we added full-text indexing (now upstream) and several performance improvements which are rather specific to our use case. We don't want to do without them and upstream aren't too interested.
This sounds like an excuse.
I don't think that Mozilla is that much better, and spot is incorrect that they don't bundle libraries (--with-system-png is commented out in F13 alpha and I know mozilla has their own brand of cairo), but with a few changes we can duplicate less work and simultaneously get a better product
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds