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
> 0.9.17)
> 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:

 Package: librdf0
 Source: redland
 Version: 1.0.10-1
 Architecture: i386
 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

Reply via email to