Depending on external libraries

[Daniel Stone]

--jRTR+8Yehy7mazmg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 11, 2004 at 04:27:19PM +0100, Egbert Eich wrote:
> Daniel Stone writes:
>  > > Right. This however was a release cycle issue. The fixes for Xrender
>  > > went into the XFree86 code as soon as a committer got around to it
>  > > - which was not always in time - but they didn't get released in
>  > > time. The theory is now that the affected lib of Xrender can be
>  > > released independently without having to release verything else.
>  >=20
>  > That was only just one example, however. I'm sure it can, will and has
>  > happened in other places.
>=20
> I'm not denying this. However I'd like to suggest to define a canonical
> set of X pieces that we are hosting on fd.o.

Err, what do you mean? Do you mean my recent blog entry[0]?

>  > > This argument however gets partly invalidated when versions of
>  > > libs get released that depend on prerelease version of other libs.
>  >=20
>  > ... so don't do that.
>=20
> Please don't tell me, tell those who do.

Bludgeoning upstreams isn't some divine privilege only I have: everyone
can do it! ;)

>  > > Right. Therefore it is necessary to clearly mark these 'external'=20
>  > > dependencies and maintain some compatibility to earlier versions of=
=20
>  > > these external APIs.
>  > > Clearly identify those 'internal' dependencies that belong together.
>  >=20
>  > I don't think necessity has been demonstrated at all. How strong a case
>  > can you make for these internal dependencies, anyway? zlib? FreeType?
>  > libxml? If you do much of your own compiling at all, you should probab=
ly
>  > have these kicking around, and they really aren't difficult to intsall;
>  > if you don't have a packaging system, a build system like jhbuild can
>  > step in and save a lot of work.
>  >=20
>=20
> I thought I made it clear that zlib, freetype etc. belong to the external
> dependencies in my definition.=20
> Why do you keep mentioning libxml? It's gone. Some pieces have been left=
=20
> in XFree86 4.4.0 - probably by accident.

Sorry, I hadn't checked recently - and haven't really checked out a
monolithic 4.4 tree, ever. The last time I was doing monolithic work was
for Debian, which, as you know, is very much 4.3.

> Just to state it again: most libs in extra/ are indeed external dependenc=
ies.
> They are maintained outside of this project and used in different context=
s.

Yes, but the thing is, these are forked codebases - the build system
differs, often the code differs, there are release schedule issues, et
al. No matter what the intent, the reality is that forked versions are
being maintained.

>  > > be be feasable it may be time to look for an alternative.
>  > > One may have to use a newer version of an external lib for two reaso=
ns:
>  > > 1. There was a bug in an old version.
>  > >     This is an 'oh sh***' issue that can always happen. In this case
>  > >     an update of the version of the lib installed on the system
>  > >     may be necessary anyway, if the bug affects the user at all.
>  > > 2. We rely on a feature that appeared in a later version of the API.
>  > >     In this case it is upon us to provide backward compatibility
>  > >     (with loss of functionality) whereever this is feasable.
>  >=20
>  > There are bugs in old versions. There are bugs in new versions. Bugs a=
re
>  > everywhere. However, IME it's generally better to have the new version=
s,
>  > because then upstream gets more wide testing of his new code, and code
>  > quality improves as you learn/discover how best to fix a certain class
>  > of bug. Code rot isn't cool, IMO.
>=20
> I don't think I can fully follow you here. The new code gets as much
> testing as the old code did when it was new. Since it did get widespread
> testing the bugs should have been fixed - at least if there have been
> maintenance releases. The new version may have these bugs fixed, too,
> but it also has new features which may contain new bugs.
> That's why one likes to give code good public exposure and 'soak time'
> to find problems. When you are a commercial entity and you have
> business customers it may even be necessary to backport bug fixes to
> older versions as migrating to newer versions with new bugs is not=20
> feasable.

Yes, but if I was maintaining a library, and someone asked me about a
bit of code in my last release, I'd likely be able to give them an
answer very quickly, probably off the top of my head. OTOH, if someone
asks me a question about code that's changed 17 times since 1998, where
the code dates from, I'm far less likely to remember and/or be useful.

So, to me, while the new version will certainly have newer, different,
bugs, I'm far more comfortable with that. It will be getting exposure in
the world outside of X (Expat, for instance, is used far more widely
than just in X), the developers will be more familiar with the code, and
more likely to help. It also makes co-ordinating security fixes several
zillion times easier, as demonstrated by the zlib fiasco.

Also, I understand the whole backporting thing - I'm a Debian Developer,
remember.

>  > I don't think external-dep problems are harder to track down: on the
>  > contrary, the newer versions are always more widely deployed, and
>=20
> I doubt this.

Which versions of Expat are distributions shipping as their common-use
lib for everything to link to? The newest upstream version, or some
random forked X version?

By distributions, I mean Linux distributions, the BSDs, OS X, Solaris,
everyone.

>  > they're a known quantity to upstream, not some random fork they haven't
>  > looked at the base of since 1997. Upstreams are also usually more
>  > willing to provide support and/or fixes for problems that occur in new=
er
>  > code.
>=20
> Code that has been there since 1997 and used since then may not be bug fr=
ee
> but one can be pretty certain that the bugs that have not been found will
> not bother anybody. This may not be entirely true for security issues,
> though.

Bugs always bother people - it's just a matter of how much. I also don't
think we can afford to have anything but a proactive approach to
security, especially given we have a massive, very-widely-deployed, suid
root binary under our control. Oh, it also listens on the network.

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

--jRTR+8Yehy7mazmg
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAUc7ucPClnTztfv0RApyzAJ0eMWQ0q9DIvYvO8ruqHVBrZgW+8wCgjSm3
0DNIOX/USrNoPqsfYp3+fMk=
=rYm9
-----END PGP SIGNATURE-----

--jRTR+8Yehy7mazmg--