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

Re: aspell upgrade woes

On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> >> It's a C++ library and the ABI changed due to being compiled with GCC
> >> 4.0.

> >> [Actually, although it's written in C++, AFAIK it only exports a C
> >> interface so the transition may not have been necessary.  I only
> >> realized this yesterday though and I'm not entirely sure a
> >> non-transition would be safe.]

> > Heh.  I've just confirmed this...

> > As with libGLU, libaspell is used in enough places that there's a
> > definite benefit to not breaking package compatibility unnecessarily.
> > Since libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the
> > only way to provide full compatibility is with two real packages.  I
> > would suggest restoring libaspell15, and creating a dummy
> > libaspell15c2 package that depends on libaspell15 and can be dropped
> > once everything has been rebuilt to use libaspell15 again; that would
> > minimize the disruption caused by the flip-flopping of the lib name.

> > Brian, if you agree, I'm happy to prepare a patch.

> Reintroducing the libaspell15 could cause problems with /usr/bin/aspell,
> since it actually goes outside the C API of libaspell and uses C++
> linkage to some symbols.  I "fixed" this bug (#307481) by making
> aspell-bin (or now just aspell) depend on the Source-Version of
> libaspell.

> However, that fix is not in the stable package of aspell.  In stable,
> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
> of just libaspell15 would break aspell-bin.  I suppose I could make the
> new libaspell15 conflict with the old aspell-bin, but that's rather
> clumsy and could make upgrades even more awkward.

> I'm not sure what the best thing to do would be.  I'm sort of inclined
> to just stick with the transitioned libaspell15c2...

Well, using libaspell15c2 will definitely cause some complexity on the
upgrade path from sarge to etch.  I don't know how much having libaspell15
conflict with aspell-bin (<< $version) would do so.  I suspect that it
would be substantially less since there are only four packages in sarge
which depend directly on aspell-bin or aspell, vs. 61 packages which depend
on libaspell15 -- at a minimum, the worst-case scenario when conflicting
with aspell-bin (<< $version) looks substantially better.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: