On Fri, 20 May 2005, Rankin, SE (Stephen) wrote:

> I wasn't sure if that particular version was required. One important
> point to consider now is building binaries that will last for a while,
> so is it best to:
> 1. Build a JPEG version ourselves, which may break over time, or
> 2. Allow the software it depends on to break over time, because newer
>    versions of JPEG are incompatible?
> I would like to supply a known working version, but this could be one
> from a Linux distribution or from some other source, I am not fussy. It
> would probably be best to get the latest one available if it works.


in the case of JPEG the code base has been stable for quite sometime now,
the version we have is from 1998, and is as far as I know the same version
(give or take tweaks to the build system, not code) as is used in all
Linux distributions, so my guess is that this is one we don't need to
worry about. If we leave it in place it should be easy to make it work
like a standard package, if that ever becomes necessary.

> Also, what exactly is the issue with the TK/TCL versions? Are the
> versions we supply the only ones that will work?

As far as it's known, yes.

> GAIA has its own versions built into its source too, doesn't it?

Yes, GAIA makes much more extensive use of Tcl internals, and several
extension packages, so upgrading is a job that needs care. Been on my list
for way too long, guess it'll stay that way.

I'm thinking about the Tcl/Tk distribution issues. Two obvious solutions
seem to have been used, make a single "tcltk" src rpm that creates a bunch
of binary rpms (in our case this would be the whole of "tclsys"), or
install the missing parts of Tcl into some private directories and hack Tk
to pick these up. I guess your system might be thrown by merging rpms?