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

[Andreas Beckmann]

On 03/12/2019 16.19, Simon McVittie wrote:
> 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>.

ACK

> 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 don't remember the details, but perhaps VDPAU_MODULEDIR was not
working as intended in all cases and libvdpau was looking (only) in the
wrong location. That was the time where we still had a biarch package ...

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

I think that patch can go away now.


Andreas