[Mesa-maintainers] Dealing with conflicting files [Re: Downstream patches and package recipes

[Andreas Boll]

2017-02-23 11:39 GMT+01:00 Emil Velikov <emil.l.velikov at gmail.com>:
> On 23 February 2017 at 10:10, Andreas Boll <andreas.boll.dev at gmail.com> wrote:
>> 2017-02-22 15:31 GMT+01:00 Emil Velikov <emil.l.velikov at gmail.com>:
>>> [splitting out of the main thread]
>>>
>>> On 22 February 2017 at 13:52, Pedretti Fabio <pedretti.fabio at gmail.com> wrote:
>>>> I can see an issue with swrast and i915, both have classic and gallium
>>>> versions. They can be both built fine, but they get installed in the same
>>>> dri directory and one (apparently the gallium one) overwrite the other.
>>>> There should be a way to be able to build and install both without special
>>>> tricks and have a way the use can select one or the other.
>>>>
>>> Thanks for bringing this up Fabio.
>>>
>>> At the moment, we have:
>>>  - cases where the files are overwritten at install stage
>>> swrast being the most common one - oibaf PPA, Debian/Ubuntu (?), Arch,
>>> Suse, Fedora (?)
>>
>> Debian & Ubuntu don't overwrite those files because they never build both
>> swrast at the same time.
>> It's split in architectures where llvm is enabled:
>>  -> building gallium swrast only
>> and architectures where llvm is disabled:
>>  -> building classic swrast only
>>
> Well placed the question mark ;-) Thanks for the correction.
>
>>>  - special handling for classic vs gallium files
>>> Manage which one is picked via a script/tool - Gentoo (I really like
>>> the approach)
>>>  - building only one of the two
>>
>> Exactly what Debian & Ubuntu are doing.
>>
>>> Nearly nobody builds i915g.
>>>
>>> What we need - make install should:
>>>  - produce correctly named files
>>>  - place them where such they can be used
>>>
>>> At the same time:
>>>  - at runtime, there is no clear heuristic to check if the classic or
>>> gallium one is required.
>>>  - we cannot retroactively fix old mesa (libGL/libEGL/libgbm) and
>>> xorg-server (libglx.so) loaders
>>>
>>>
>>> Thus the following ideas that come to mind (in order of personal preference):
>>>  - use/import library management similar to the Gentoo one
>>>  - make them mutually exclusive, similar to {classic,gallium}osmesa
>>>  - rename to {swrast,i915}g_dri.so and add fallback(s) in the loaders
>>> Icky, retro-fix old mesa/xorg ?
>>>  - deprecate (from build perspective) classic swrast,  i915g
>>
>> Debian & Ubuntu:
>> We don't build i915g (only classic i915) and we are trying to deprecate classic
>> swrast on most architectures.
>> I'm planning to enable llvm on more architectures but unfortunately not on all.
>>
> Need to check with devs, if this will fly. In the meanwhile do you see
> any alternative solutions, do you think that any of my other
> suggestions are forth the shot ?

I'd vote for:
 - make them mutually exclusive, similar to {classic,gallium}osmesa

Shouldn't be that much work and would also be a step into deprecating classic
swrast.
Furthermore I'd add a deprecation warning if one enables classic swrast.
IMO people should really use llvmpipe and only build classic swrast if one can't
use llvm for some reason.

> Note that I'm not saying that you should implement them.
>
>> Btw we are also deprecating OpenGL ES 1 support.
>>
> That will "go away" from Mesa, soon (tm).
This would also be a candidate for a deprecation warning.

Thanks,
Andreas