Depending on external libraries

[Kendall Bennett]

Egbert Eich <eich@pdx.freedesktop.org> wrote:

> A self contained tree has its merits, you can build it on about
> any system that comes with little more than a compiler. On the
> other hand we already had some kind of external dependencies.
> libpng is one example. 
> 
> The disadvantage of the self contained system is that someone has
> to go and update things and Imake-ify them. I just went thru this
> with freetype2. It was not a great big deal - but this would have
> to be done once per release. If we are going to have more frequent
> releases we sure would have to find someone to do it for every
> release. 

The danger of having external dependencies is that you run into code rot. 
Stuff that no longer works because of depending on an external piece that 
has changed since the official release was made. To avoid this you need 
to rely on exact versions of external code that you know will work with 
the X tree, but if the release schedules for those external pieces do not 
line up, you have serious problems. At some point you may need patches 
made to say v1.2.3 of some external piece to get it working reliably with 
all platforms supported by X, but after the release 1.2.4 comes out and 
breaks the X support again. So the user cannot use eithe v1.2.3 *or* 
v1.2.4 as official external released because neither version works.

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. 

> Asking people to pull such things from an external source may not
> be too much to ask if we detect the missing pieces reliably and
> early in the build and instruct the user where to get them. 

IMHO asking people to pull these pieces from an external source is just 
asking for trouble down the track. There is no way to properly certify 
that the 'system' or 'component' you are interested in is really going to 
work unless the external version works completely *unchanged* for your 
component (ie: no patches required from an official release you can 
download from an external server).

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.

IMHO it would be more prudent for a vendor wishing to see new 
functionality in say a later release of FreeType deployed in their 
distro, spend the time to merge in the latest version of FreeType and 
iron out the issues in the *main tree* rather than just for their distro. 
That way everyone benefits from this work, and there will be a lot less 
duplication off effort.

After all isn't one of the reasons this X.org version of the X server got 
started was to avoid all the duplication of effort among the distro 
vendors because they couldn't easily get their patches and changes back 
into the core system? If that barrier is significantly lower, there is no 
reason why the copies of the library code inside the CVS tree cannot be 
easily updated by those interested in new features and functionality 
provided by updated versions of external products. Upgrading for the sake 
of upgrading is a pointless exercise - unless there is some tangible 
benefit to using a later version of FreeType or some other library (bug 
fixes, performance enhancements or new features), using it when it may 
cause problems seems a little silly.

Just my $0.02 on this issue based on our experiences building binary 
portable software.

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! ~