[Aptitude-devel] Bug#863705: Bug#863705: aptitude: symbol lookup error: aptitude: undefined symbol:

[Olly Betts]

So if I understand the issue correctly, it's that libxapian30 in
unstable is built with the new C++ ABI while libxapian30 in backports
was built with the old C++ ABI, so really should have been libxapian30v4
or something (not sure if there's a reverse convention to the v5
suffix)?

Sorry for not spotting that when I did the backport.  It worked fine in
my testing in a jessie environment - I guess you only see problems if
you try to run a mixed jessie/stretch environment.  Or perhaps if you
try to do the upgrade to stretch using aptitude.

On Tue, May 30, 2017 at 10:51:19PM +0200, Axel Beckert wrote:
> Hi Sven,
> 
> Sven Joachim wrote:
> > Control: reassign -1 libxapian30 1.4.1-1~bpo8+1
> 
> I wouldn't be so quick with reassigning.
> 
> > > aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK6Xapian8Database14postlist_beginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> > 
> > This happens because libxapian30 from jessie-backports is not compatible
> > with libstdc++6 from unstable
> 
> Hrm, this sounds to me as if aptitude's dependency on libxapian30
> should be more tight.

That addresses this for aptitude, but not other rdeps.  It's perhaps a
worse issue for aptitude, as you don't want your package management tool
broken while trying to upgrade packages.

> Or maybe even better: libstdc++6 should break with this version of
> libxapian30 from backports.

This seems to address the wider problem, but rather feels like it's
addressing it in the wrong place.

I can try to fix the xapian-core version in backports, but that only
helps people with 1.4.1-1~bpo8+1 installed if they upgrade from
backports before trying to mix in packages from stretch.

Not sure quite how much work that would be - it'll require coordinating
uploads of the rdeps using the backported xapian-core, but I don't know
of the top of my head how to get a list of those.  I know there's
xapian-omega; I thought notmuch was too, but that still seems to be on
libxapian22.

Cheers,
    Olly