Dave Beckett <d...@dajobe.org> writes:
>>From the stack trace I can see a problem - the librdf is calling the old
> rasqal ABI (0.9.16) in librasqal.so.1 rather than the new (0.9.17) in
> librasqal.so.2. (Assuming these are redland librdf 1.0.10 and rasqal librdf
> redland 1.0.10 (librdf.so.0) was packaged to link with the new rasqal 0.9.17
> (librasqal.so.2) and so the above stack trace should not be possible, unless
> I've got the shared lib/package dependencies wrong.
Let's check the reporter's versions:
ii librasqal1 0.9.16-2 Rasqal RDF query library
ii librdf0 1.0.10-1 Redland Resource Description Frame
Hm. Let's check the package dependencies:
Depends: libc6 (>= 2.3), libdb4.8, libltdl7 (>= 2.2.6b), libraptor1 (>=
1.4.19), librasqal2 (>= 0.9.17)
We see that ardour links against librasqal1, while librdf0 links against
librasqal2. This indicates a problems with transitive dependencies of
the rasqal package: Both versions are loaded into the address space of
the application, probably with colliding symbols.
> Maybe librasqal2 should conflict with librasqal1.
With the conflicts you prevent both libraries to be co-installed and
cause potentially a difficult transition for the 'testing' migration.
Have you analyzed how many packages are affected by this? All reverse
dependencies on librasqal1 need to be transitioned. If this affects a
larger portion of packages, this might warrant a discussion on
debian-release or debian-devel.
The most elegant solution i see here would be to introduce symbol
versioning in the librasqal package so that applications that have not
been transitioned yet to librasqal2 package can easily co-exist.
BTW, I'm currently doing essentially the same in the ffmpeg package atm.
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list