[Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"

[Dave Airlie]

Is it missing an R-b?

Reviewed-by: Dave Airlie <airlied at redhat.com>

can you just push it now?

Dave.

On 7 October 2014 11:36, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Oct 6, 2014 at 9:11 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 05/10/14 01:26, Ilia Mirkin wrote:
>>>> On Fri, Oct 3, 2014 at 3:43 AM, Christian König <deathsimple at vodafone.de> wrote:
>>>>> Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
>>>>>
>>>>>> On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 02/10/14 06:41, Ilia Mirkin wrote:
>>>>>>>>
>>>>>>>> On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 29/09/14 17:24, Matt Turner wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
>>>>>>>>>> <emil.l.velikov at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> So all in all we have the following:
>>>>>>>>>>>
>>>>>>>>>>> Some distributions/people choose odd location of the modules. Which
>>>>>>>>>>> can lead to the system (vdpau/omx) looking at the wrong place for the
>>>>>>>>>>> backends, i.e. not working. One can consider that there is no way to
>>>>>>>>>>> override the module location at runtime.
>>>>>>>>>>
>>>>>>>>>> Do we have more specifics? If they're doing something stupid and it
>>>>>>>>>> breaks, they typically get to keep the pieces.
>>>>>>>>>>
>>>>>>>>>> Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
>>>>>>>>>> ${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
>>>>>>>>>>
>>>>>>>>> Hmm I was under the impression that ${libdir} and
>>>>>>>>> /usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
>>>>>>>>> a
>>>>>>>>> volunteer for the following, even if the chances of it happening are
>>>>>>>>> zero ?
>>>>>>>>>
>>>>>>>>> On 29/09/14 17:16, Emil Velikov wrote:
>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> How many volunteers do we have that will guide Debian/Ubuntu/other to
>>>>>>>>>> do the correct thing ? If we have at least one, I will be OK with
>>>>>>>>>> reverting the patch.
>>>>>>>>
>>>>>>>> Guide who? The maintainers? Sure, I'll happily help them out.
>>>>>>>>
>>>>>>> Pretty much everyone that reports a bug/send an email to the ML/posts a
>>>>>>> big and flashy "review" along the lines of "vdpau/omx/va is
>>>>>>> useless/broken" like YKW.
>>>>>>>
>>>>>>> The numbers/reports will be low (if any), but the encounters are likely
>>>>>>> to be quite "interesting".
>>>>>>
>>>>>> I'm more than happy to enlighten people as to why what they're doing
>>>>>> is wrong. I guess this patch is good then?
>>>>>
>>>>>
>>>>> You need to implement the same for the OMX target as well, since the
>>>>> intention was to get a consistent behavior.
>>>>
>>>> Unfortunately I don't know anything about OMX.
>>> Do I take that you've missed that my volunteer request covers vdpau, omx and va ?
>>
>> I'm under the assumption that OMX/etc don't do anything ridiculous. If
>> they do, it's a bug just like this vdpau situation, and should be
>> addressed as such. However addressing them should not preclude vdpau
>> from being fixed.
>>
>> I'm getting this >< close to just not building vdpau anymore due to
>> this breakage.
>
> What I'm really perplexed by, by the way, is the lack of people
> jumping in to R-b this. There have been a few weak "yes, this is bad"
> but no R-b. I would have thought that installing outside of the prefix
> is such an obvious no-no that a change introducing that would just get
> insta-reverted. But perhaps I'm wrong, and people do expect random
> system files to get overwritten when they run 'make install' despite
> having explicitly said it should install somewhere else, and I should
> just crawl back into my hole instead of trying to get the kids to stop
> playing on my damn lawn.
>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev