Andres Mejia wrote:
> One concern I have is with the trace library, libvdpau_trace.so. If this
> library is not going to supply any versioning, than this library should reside
> in a subdirectory in /usr/lib. For example, we could follow the same scheme
> adopted by pulseaudio, have the trace library installed in
> /usr/lib/vdpau-0.2/modules.
As I understand it, both libvdpau_trace.so and libvdpau_$VENDOR.so (with
$VENDOR = nvidia for now) are "plugins", dlopen()ed from libvdpau.so.1
(and have no proper versioning like most plugins).
So if the wrapper can be patched to search in a subdirectory of /usr/lib
(and /usr/lib32 or /usr/lib64 where appropriate) both the trace library
and the vendor implementation can be moved out of /usr/lib{,32,64}
For the subdirectory something like just /usr/lib/vdpau or
/usr/lib/vdpau-$PLUGINABI might be a better choice, as the interface
(version number) of the vdpau wrapper might evolve while staying "plugin
compatible" (using some kind of capability interface).
Or /usr/lib/vdpau for the vendor implementation, /usr/lib/libvdpau1 for
the trace library/plugin (which will always match the wrapper library
because they are supplied by the same package, so no ABI issues at all
involving the trace library)
> If the library is to be ABI compatible across different revisions, than
> versioning info should be added to the library instead.
BTW, what about building a lib32vdpau1 package on amd64, too? This will
be needed by libvdpau*-nvidia-ia32. Or are there chances to get
libvdpau1 into ia32-libs(-whatever) in time?
Andreas
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
