Re: [tetex-3.0] beta for tetex-3.0, release plan for Debian packages?
Frank Küster writes:
> Hilmar Preusse <hille42@web.de> schrieb:
>> On 26.02.04 Frank Küster (frank@kuesterei.ch) wrote:
>>> One major issue is that libkpathsea has a new soname, libkpathsea.so.4
>>> Since many packages will want to link against libkpathsea3, we will have
>>> to provide a legacy package for them.
>> No I guess not. We have just to find out, which packages link to
>> libkpathsea3 and start to file bug reports against these packages as
>> soon as libkpathsea4 has been uploaded. The packages normally just
>> need a rebuild. Yes, this will take time and we shouldn't do that if
>> we know, sarge is just a few weeks ahead.
> This would be ideal. It the world is less ideal. It's not only a
> question of timing. It might also be that programs don't work with the
> new versin. Olaf Weber said that in fact binary compatibility cannot be
> guaranteed between different web2c versions that alls generate
> libkpathsea.so.3, because libkpathsea wasn't designed to be a shared
> library at all.
Allow me to clarify a bit.
libkpathsea moved from using klibtool (a web2c-specific libtool-like
hack) to libtool. As a result it acquired a new soname (and I'm not
particularly happy with the way libtool picks sonames, but that's
another discussion).
libkpathsea was not designed to work well as a shared library, and has
numerous flaws in that area -- in particular, too many internals are
exposed, and too much is hard-coded.
On the other hand, the interface that people are expected to use has
been fairly stable, which means that most programs should continue to
work when the library is upgraded. 'kpsewhich' is special, it has to
be an exact match with the library version. But I believe the other
programs in the web2c suite will continue to work even if the library
is upgraded. However, using a program that with a "downrev" version
of the library is definitely asking for trouble.
But, with the internals exposed the way they are, it is hard for me to
give absolute guarantees, as opposed to observing that something is
likely to work. Certainly, if it turns out that things don't work,
upstream (e.g., me) is likely to note that the problem is not really
fixable without redesigning the library.
So at present my advice is that it's better to be safe than sorry, and
enforce that the version of libkpathsea matches the program's version.
> He's planning (or doing) a rewrite which will be named libkp or
> something like that. But for the time being, we should not be too
> surprised if we get problems with libkpathsea4.
Doing (for reasons that should be clear), and its working name is
libkpse.
--
Olaf Weber
(This space left blank for technical reasons.)
Reply to: