Bug#946063: libvdpau: please document reason(s) for d/p/vdpau-module-searchpath.patch (or consider dropping it?)

[Simon McVittie]

Source: libvdpau
Version: 1.2-1
Severity: wishlist

While investigating VDPAU driver discovery I noticed that the Debian
libvdpau package has a 2011 patch to search for VDPAU drivers in:

* "${ORIGIN}/vdpau"
* VDPAU_MODULEDIR
* "/usr/lib/vdpau"

instead of the upstream behaviour of searching only VDPAU_MODULEDIR.

The original patch that was proposed on #631174 by Daniel
Schaal literally added /usr/lib/vdpau to the search path,
and nothing else. However, Andreas Beckmann later replaced
it with one that added the ${ORIGIN}/vdpau entry, in
<https://salsa.debian.org/nvidia-team/libvdpau/commit/90d87bbef0168a890a7b0cba28f88f49c6772413>.

Since then, the Debian patch has been incorporated
into Buildroot (and possibly other non-Debian-derived
distributions), and has been proposed upstream in
<https://gitlab.freedesktop.org/vdpau/libvdpau/merge_requests/5>.
However, it doesn't come with a rationale.

>From #631174, I'm assuming that hard-coding /usr/lib/vdpau was
a Debian-specific backwards-compatibility mechanism to handle the
transition from /usr/lib to /usr/lib/${DEB_HOST_MULTIARCH}, similar to
patches that were applied in packages like GTK and GLib around the same
time: libvdpau had to continue to search the old path /usr/lib/vdpau in
addition to the new path /usr/lib/${DEB_HOST_MULTIARCH}, otherwise it
would have broken the older VDPAU drivers.

If that's the case, that part of the patch can perhaps go
away now? All the VDPAU drivers in Debian, contrib and
non-free seem to be in multiarch directories now. This
would be similar to GTK dropping its equivalent patch in
<https://salsa.debian.org/gnome-team/gtk3/commit/c565c0af222de5b13031381c38a351113548de67>.

It isn't clear to me why the ${ORIGIN}/vdpau part was included. Is that
something Debian still needs to patch? Does the reason Debian needs it
apply equally to upstream?

It looks to me as though searching ${ORIGIN}/vdpau is redundant with
VDPAU_MODULEDIR, unless Debian's libvdpau.so.1 is copied (relocated) into a
non-standard prefix and used from there, which is not something that Debian
packages are usually designed to support - but perhaps there's a
VDPAU-specific reason that I'm not seeing?

I'm opening this bug in the hope that Andreas or someone
else who was involved at the time can clarify, because
I would like to avoid some future maintainer having to
dig up reasons for patches 10+ years after they happened in
order to understand whether they are still desirable, like I did in
<https://salsa.debian.org/gnome-team/gtk3/commit/afa6bbf07dd26e74c72d37584939d3690a935b39> :-)

Thanks,
    Simon