Depending on external libraries
Thu Mar 11 01:36:12 PST 2004
Daniel Stone <firstname.lastname@example.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
> > 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.
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
~ SciTech SNAP - The future of device driver technology! ~
More information about the release-wranglers