On Sat, Jan 25, 2014 at 4:19 PM, Mike Gilbert <flop...@gentoo.org> wrote:
> On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert <flop...@gentoo.org> wrote: > > On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny <mgo...@gentoo.org> wrote: > >> Dnia 2014-01-25, o godz. 11:13:38 > >> Mike Gilbert <flop...@gentoo.org> napisał(a): > >> > >>> It seems having XDG variables like XDG_CONFIG_HOME set in the > >>> environment when calling emerge has a tendency to cause sandbox > >>> violations. For example, see the bugs blocking bug 499202. > >>> > >>> https://bugs.gentoo.org/show_bug.cgi?id=499202 > >>> > >>> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see > >>> that several eclasses work around this by setting > >>> XDG_CONFIG_HOME="${T}" or "${T}/.config". > >>> > >>> gnome2-utils.eclass takes it a step further and creates empty > >>> directories for several other XDG variables. > >>> > >>> Is this something we can/should consolidate into some central place? > >>> Or should I just copy/paste something into distutils-r1.eclass? > >> > >> I'd say portage should kill that as part of sanitizing the environment. > >> There's no point in reproducing it in random eclasses. > >> > > > > I have filed an enhancement request for Portage. > > > > https://bugs.gentoo.org/show_bug.cgi?id=499288 > > It seems Arfrever beat me to it. However, it looks like it would need > to be an EAPI change, which means quite a long wait. > I don't buy that. The behavior appears to be currently undefined. Changing it to different undefined behavior is allowed. If EAPI-NEXT wants to define the behavior of XDG_* then that is fine too, we will just be ahead of the curve, rather than behind. -A > > https://bugs.gentoo.org/show_bug.cgi?id=444568 > >
