Depending on external libraries
Wed Mar 10 23:32:29 PST 2004
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 10, 2004 at 11:15:40AM -0800, Kendall Bennett wrote:
> Egbert Eich <firstname.lastname@example.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.=20
> > 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.=20
> 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=20
> 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*=20
> 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=20
> code. That way you don't end up with serious gotchas in the field with=20
> varying versions of external pieces being used.=20
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
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).
> > 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.=20
> 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=20
> that the 'system' or 'component' you are interested in is really going to=
> work unless the external version works completely *unchanged* for your=20
> component (ie: no patches required from an official release you can=20
> download from an external server).
Their distributor should also provide them: we should be doing this if
there is a clear expectation that your distributor will provide a
certain package (e.g. zlib). Beyond here we're possibly talking about a
monolithic/modular architecture, which seems to be too much of an
emotionally-charged topic to be objective.
> Note also that the policy of including all the source to build the=20
> 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=20
> 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.
=46rom 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?
> IMHO it would be more prudent for a vendor wishing to see new=20
> functionality in say a later release of FreeType deployed in their=20
> distro, spend the time to merge in the latest version of FreeType and=20
> 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.
We're talking about forking every single library for no reason.
> 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=20
> 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=20
> provided by updated versions of external products. Upgrading for the sake=
> of upgrading is a pointless exercise - unless there is some tangible=20
> benefit to using a later version of FreeType or some other library (bug=
> fixes, performance enhancements or new features), using it when it may=20
> cause problems seems a little silly.
Duplication of libraries seems a lot like duplication of effort to me.
> Just my $0.02 on this issue based on our experiences building binary=20
> portable software.
I'll have to defer to your experience there.
Daniel Stone <daniel@freedesktop=
freedesktop.org: powering your desktop http://www.freedeskto=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the release-wranglers