[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libkpathsea3 incompatibility problem



On Wed, Feb 19, 2003 at 01:20:46PM +0000, Julian Gilbey wrote:
> 
> There's a major problem with the new tetex-* packages, and in
> particular with the new libkpathsea3 package.  Because upstream broke
> binary compatibility with previous versions (and as they have stated,
> they are not yet supporting the building of libkpathsea as a shared
> library), there are now several packages which are broken because of
> this (all of which have been Bcc'd on this email):
> 
> $ grep-available -F Depends libkpathsea3 -s Package,Version,Depends
[snip]
> Package: jtex-bin
> Version: 1.8-5.1
> Depends: jtex-base, tetex-bin, libc6 (>= 2.3.1-1), libkpathsea3 (>= 1.0.7+20021025-3)
[snip]

Just to make this funner... (This is also documented in Bug #180420
against jtex-bin)

The new tetex-bin package conflicts with jtex-bin for some reason
involving conf files or something. (I don't ask questions, I just use it
:-)

Sadly, if libkpathsea3 is upgraded before jtex-bin is removed (since it
doesn't conflict with anything and I wanted to know _why_ I was losing
jtex before I let it happen) then the jtex-bin prerm can't do
something (I forget what) since it tries to run something linked to the
old libkpathsea3 which segfaults with the new one.

The error that comes out is that your tetex.cnf or somesuch is broken,
please purge tetex-bin or whichever. (Precise description, eh?) Anyway,
the relevant configuration file is apparently fine, it's the program
which is segfaulting.

Simply reinstalling the old libkpathsea3, purging jtex-bin and
re-upgrading made everything work fine. I think I was lucky I only
had the one program that used something linked against libkpathsea3
in it's pre-rm, but...

I assume more people aren't hitting this because they're not upgrading
libkpathsea3 until tetex-bin goes in, so the removals are happening with
the old libkpathsea3. Or jtex-bin is unusual to use such a program in
it's prerm script maybe?

> Package: ptex-bin
> Version: 3.0.5+0.04-2
> Depends: ptex-base (>= 1:2.0-3), tetex-bin (>= 1.0.7+20011202-5.1),
> tetex-extra, libc6 (>= 2.3.1-1), libkpathsea3 (>= 1.0.7+20021025-6)
Hmm. I still have this installed. However, I don't have anything
handy to test it against... It certainly doesn't crash _immediately_.

> So now what do we do?  Presumably, all of these packages will break
> once the new libkpathsea3 is installed, so here are the obvious
> options:
> 
> (1) File RC bugs against all of these packages, requiring them to
>     recompile against the newer libkpathsea3, and have versioned
>     Conflicts: with the old versions of these dozen or so packages.
> 
> (2) Change the so version number of the libkpathsea library to 4, even
>     though this matches nothing in the upstream, and provide an old
>     libkpathsea3 package in oldlibs for compatibility (this would be a
>     source package entirely separate from tetex-bin derived from the
>     old teTeX sources).
> 
> (3) Like (2), but change the so version number to 0 to indicate
>     unstable interface.
> 
> I prefer (2) or (3).  Other comments?

I'm inclined towards #1, since I don't like so version creep if we can
avoid it... Is upstream going to support a shared libkpathsea3 any
time soon? (IE Will they ever stop breaking the interface?)

On the other hand, if we could convince them to use whatever so version
we're upto when they decide to lock down the interface, then creep
ahead!

Oh, BTW, are they breaking the API here? Or is it something else
happening so that a simple recompile _will_ fix those packages?
eg API extension (which I understood to not cause segfaults)

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
5th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------

Attachment: pgpDCPg47HTKr.pgp
Description: PGP signature


Reply to: