Depending on external libraries
Fri Mar 12 14:53:34 PST 2004
Content-Type: text/plain; charset=us-ascii
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.
> > That was only just one example, however. I'm sure it can, will and has
> > happened in other places.
> 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?
> > > This argument however gets partly invalidated when versions of
> > > libs get released that depend on prerelease version of other libs.
> > ... so don't do that.
> 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=
> > > these external APIs.
> > > Clearly identify those 'internal' dependencies that belong together.
> > 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=
> > 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.
> 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=
> 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=
> They are maintained outside of this project and used in different context=
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
> > > 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=
> > > 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.
> > There are bugs in old versions. There are bugs in new versions. Bugs a=
> > everywhere. However, IME it's generally better to have the new version=
> > 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.
> 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
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,
> > I don't think external-dep problems are harder to track down: on the
> > contrary, the newer versions are always more widely deployed, and
> 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,
> > 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=
> > code.
> Code that has been there since 1997 and used since then may not be bug fr=
> 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,
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.
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