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

[Jonathan Gray]

On Thu, Feb 23, 2017 at 01:20:45PM +0100, Andreas Boll wrote:
> 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.

gallium softpipe works without llvm.  On OpenBSD we only build softpipe
and not classic swrast on all archs including some such as hppa that are
unlikely to ever get a llvm backend.