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