Depending on external libraries

[Kendall Bennett]

Daniel Stone <daniel@freedesktop.org> wrote:

> > IMHO if the X tree *requires* and depends on certain external libraries 
> > in order to work correctly, those pieces should be included in the entire 
> > X tree and built as part of that system. Sure it is more work to import 
> > the external code into the X tree on a regular basis, but the key point 
> > is that the code that finally ends up in the resulting release tree has 
> > been through the same release and testing process as the rest of the 
> > code. That way you don't end up with serious gotchas in the field with 
> > varying versions of external pieces being used. 
> 
> I do not believe this to be the case. It just causes heaps of
> heartache for completely hypothetical situations when, say, there's
> a security bug in zlib or something equally improbable. If you
> depend on a specific version because of API reasons, talk to
> upstream! If one part of the API must be absolutely rock-solid, ask
> them to keep compatibility wrappers around. 

I am not talking about API compatibility, I am talking about busted code. 
Since X supports a *lot* of different platforms, it is important that 
those libraries included work correctly on all the supported platform, 
not just the ones that get the most attention in the upstream projects.

There are few few project IMHO that are stable enough to consider just 
grabbing the latest source code and integrating it without serious 
testing on all the platforms that things need to work on.

> It just causes confusion, and it's a PITA from a distributor point
> of view (bugs in Xrender that were fixed 4 releases ago, but still
> aren't in XFree86, for instance). 

Sure, but like I said, the whole point of this new project is to 
eliminate the problem of Xrender bugs not being fixed in the X 
distribution source code. Now that lots more people will have commit 
access, Xrender should be fixed *inside* the X distribution itself 
relatively quickly, rather than going stale as has been the problem in 
the past.

> > Note also that the policy of including all the source to build the 
> > necessary pieces does not necessarily infringe on the idea of a modular 
> > build system either. You only need to keep around the pieces required by 
> > each modular part of the system as necessary. The key thing is to make 
> > sure stuff is broken up properly and that stuff is properly integration 
> > tested together as a unit.
> 
> Right, but it defeats half the point, IMO. I will personally not
> be at all happy with any non-monolithic tree that includes external
> libraries. From a distributor point of view, it's caused me a hell
> of a lot of pain. If you depend on external libs, why not just tell
> people where to go get them? 

For a distributor who is going to put in the effort to apply patches and 
maintain their own 'working' versions of a the necessary libs, this is 
not a big deal. But for some poor schmo who loves X and just wants to get 
his feet wet building the latest code from X.org or whatever, it can be a 
really serious problem if the code won't build or even work if that 
developer has outdated libraries.

One of the things that I find important is that if you have a library 
that some internal piece of your code relies on, you are are much better 
using a specific version of that libraries that works for what you need 
rather than relying on some myriad of potentially incompatible external 
libraries. Unless you are building an entire distro of course - in that 
case you have your own MONOLITHIC system to solve the problem of 
integration issues - your Linux distro.

It really depends entirely on whether you want the X server project to be 
something standalone, or something that should only ever work when 
delivered as part of a complete OS distribution. You guys keep arguing 
about the fact that you don't like a monolithic server but instead want 
modular trees and modular libraries, yet at the end of the day you are 
building the biggest monolithic system of all - your OS!

Kind of ironic eh ;-)

> Duplication of libraries seems a lot like duplication of effort to
> me. ;) 

It is more than that. My philosophy on this is that the libraries 
required by something like the X server to function correctly should be 
included with that project. 

If FreeType is something that is required to work correctly for font 
rendering to work in the X server, a version of FreeType should be a part 
of the X server proper. I could care less whether there is already a 
version of FreeType installed on the end users system as a shared 
library, or what version it is (or even that it exists and builds 
natively for the target platform). The only thing that matters is that 
the X server has it's own local copy that is correct for what *it* needs. 
It might be static linked into the server, or dynamically linked somehow 
with a different module name and path (maybe prefix important internal 
libraries with something so you know they are specific to the X server).

At the end of the day it is a trade off really. Compatibility against 
saving bytes on disk and memory by only having one copy of FreeType 
installed on the target system. I always prefer the former.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~