Depending on external libraries

[Daniel Stone]

--m1rwLFmcefDs/2Y3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 10, 2004 at 11:15:40AM -0800, Kendall Bennett wrote:
> 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.=20
> >=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
>=20
> The danger of having external dependencies is that you run into code rot.=
=20
> Stuff that no longer works because of depending on an external piece that=
=20
> has changed since the official release was made. To avoid this you need=
=20
> to rely on exact versions of external code that you know will work with=
=20
> the X tree, but if the release schedules for those external pieces do not=
=20
> 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=
=20
> all platforms supported by X, but after the release 1.2.4 comes out and=
=20
> 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.
>=20
> IMHO if the X tree *requires* and depends on certain external libraries=
=20
> in order to work correctly, those pieces should be included in the entire=
=20
> X tree and built as part of that system. Sure it is more work to import=
=20
> the external code into the X tree on a regular basis, but the key point=
=20
> is that the code that finally ends up in the resulting release tree has=
=20
> 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
around.

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
>=20
> IMHO asking people to pull these pieces from an external source is just=
=20
> 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=
=20
> 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=
=20
> build system either. You only need to keep around the pieces required by=
=20
> 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=
=20
> 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.=
=20
> That way everyone benefits from this work, and there will be a lot less=
=20
> 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=
=20
> 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=
=20
> into the core system? If that barrier is significantly lower, there is no=
=20
> reason why the copies of the library code inside the CVS tree cannot be=
=20
> easily updated by those interested in new features and functionality=20
> provided by updated versions of external products. Upgrading for the sake=
=20
> 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=
=20
> 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.

--=20
Daniel Stone                                            <daniel@freedesktop=
.org>
freedesktop.org: powering your desktop                http://www.freedeskto=
p.org

--m1rwLFmcefDs/2Y3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAT6WNcPClnTztfv0RAtEnAJoDaHkE/+qIIcRncIDp+ALW2eLgqgCdHlJs
U5MfNpmObJdYg1BdMfI8kUE=
=hcqx
-----END PGP SIGNATURE-----

--m1rwLFmcefDs/2Y3--