On Thu, Oct 01, 2015 at 01:46:10AM +0200, Marek Olšák wrote: > On Thu, Oct 1, 2015 at 1:21 AM, Marcin Ślusarz <marcin.slus...@gmail.com> > wrote: > > On Thu, Oct 01, 2015 at 12:57:40AM +0200, Marek Olšák wrote: > >> On Thu, Oct 1, 2015 at 12:53 AM, Marcin Ślusarz > >> <marcin.slus...@gmail.com> wrote: > >> > On Wed, Sep 30, 2015 at 09:35:45PM +0200, Marek Olšák wrote: > >> >> On Mon, Sep 28, 2015 at 5:56 AM, Michel Dänzer <mic...@daenzer.net> > >> >> wrote: > >> >> > On 03.09.2015 07:26, Marek Olšák wrote: > >> >> >> On Wed, Sep 2, 2015 at 10:56 PM, Kenneth Graunke > >> >> >> <kenn...@whitecape.org> wrote: > >> >> >>> On Wednesday, September 02, 2015 02:26:56 AM Marek Olšák wrote: > >> >> >>>> From: Marek Olšák <marek.ol...@amd.com> > >> >> >>>> > >> >> >>>> A user can be using Mesa 11.0, but /etc/drirc can be from Mesa > >> >> >>>> 10.5. > >> >> >>>> We don't want the old drirc to affect Mesa 11.0. > >> >> >>>> > >> >> >>>> There are 2 options: > >> >> >>>> - use a different file name (e.g. /etc/drirc_global) for people > >> >> >>>> wanting > >> >> >>>> a global drirc file, but they must supply it by themselves > >> >> >>>> - just don't load it, users should use ~/.drirc > >> >> >>>> > >> >> >>>> This patch implements the latter. > >> >> >>>> --- > >> >> >>>> src/mesa/drivers/dri/common/xmlconfig.c | 18 +++++++++--------- > >> >> >>>> 1 file changed, 9 insertions(+), 9 deletions(-) > >> >> >>> > >> >> >>> I don't really get the rationale. /etc/drirc could be properly > >> >> >>> managed > >> >> >>> by the package manager - shipped alongside *_dri.so in the same > >> >> >>> package. > >> >> >>> Maybe it isn't today, but it could be handled well. > >> >> >>> > >> >> >>> But ~/.drirc is entirely in the users control. Neither the distros > >> >> >>> nor > >> >> >>> us can manage what the user puts there. It's *very* likely to be > >> >> >>> stale... > >> >> >> > >> >> >> The idea is that ~/.drirc should only contain options like an > >> >> >> anisotropic filtering override and other useful overrides. Hacks > >> >> >> which > >> >> >> remove features or change the GLSL compiler behavior should not be > >> >> >> part of it. > >> >> > > >> >> > One issue with this is that the driconf GUI seems to always write all > >> >> > options to ~/.drirc. I ended up with stale workaround entries for > >> >> > Unigine demos in ~/.drirc before like this. > >> >> > >> >> I wish there was a simple solution to the .drirc mess. Unfortunately, > >> >> the one that I had suggested was rejected. > >> >> > >> >> Another solution to my issue is to have a different drirc filename for > >> >> each Mesa version, e.g. drirc.10.6, drirc.11.0. > >> >> > >> >> For your issue, the only way is to remove loading ~/.drirc from Mesa, > >> >> making driconf useless. Do we really care about driconf? I don't think > >> >> so. > >> > > >> > Or we can load both ($sysconfdir/drirc and ~/.drirc) and merge them. > >> > >> No, that wouldn't make any difference whatsoever. Mesa 11.0 removed a > >> few lines from drirc. You can't merge something that was removed. > > > > Ok, another approach: > > - drop ~/.drirc support > > - add support for ~/.drirc.patch which can both add and remove options > > from $sysconfdir/drirc (eg attribute remove="true" at any level) > > - teach driconf to generate ~/.drirc.patch > > > > What do you think? > > Too complicated and I don't think people will be eager to update > driconf. Why not this: > > - drop ~/.drirc support > - install drirc to and load it from $sysconfdir/drirc.$major.$minor
After step 1, step 2 should not make any difference - you cannot install multiple packages providing the same file and private installations are already handled (drirc is installed to $prefix/etc/ and loaded from there). Marcin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
