[Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc1

Emil Velikov emil.l.velikov at gmail.com
Thu Oct 20 15:11:51 UTC 2016


On 19 October 2016 at 20:31, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Wed, Oct 19, 2016 at 12:16 PM, Emil Velikov <emil.l.velikov at gmail.com>
> wrote:
>>
>> On 19 October 2016 at 19:50, Kai Wasserbäch <kai at dev.carbon-project.org>
>> wrote:
>> > Hey Emil,
>> > just curious why you did the revert
>> >
>> > (<https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04>).
>> > Wouldn't distros just set --disable-vulkan-icd-full-driver-path (I know
>> > I'm
>> > doing that for Multi-Arch compatibility for my local builds)?
>> >
>> Yes they can, yet they shouldn't need to bother to begin with, since
>> the code itself is not aimed at deployment ;-)
>
>
> What code isn't aimed at deployment?
>
> Don't just go reverting commits in the release branch on your own authority
> with no discussion.  If that flag is causing problems for distros and
> packagers, let's hear from them and they can tell us what they need.
>
I believe I mentioned it before - due to the high traffic on mesa-dev@
little-to-no distro maintainers get to read upon decisions and/or cast
their opinion. In most cases they'll just workout something locally
and not bother (-ETIME or other) prodding upstream.

I believe I explained it in length why the original and follow up are
bad idea, suggested two alternative solutions and a Nack on the patch.
Only to get all that fall though the cracks :-\

> Also, it's not in there for developers.  It's in there for people who want
> to do a local build and have "make install" work somewhat correctly.
Doing `make install' to a non-default prefix falls in the
development/testing category.

In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
software that one's building/testing. That is unless you're using
chroot :-)

> They're free to do that local build from a release branch or a tarball and
> it should still work.


>  Also, you're making piles of pain for packagers who
> now have a configure flag that works in 12.0 git and 13.0 git but in 13.0
> release it is gone.
Please don't get me wrong, but I think you're over-dramatizing this a
little. Can you be specific where this has caused/will cause pain ?

I regularly check what distros do and try to steer them as things get
rocky. The revert helps exactly this - it removes the "pain" that it
would cause to distros since there's a) new option and b) the default
value of it is _against_ their preference.

Thanks
Emil


More information about the mesa-dev mailing list