On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue <e...@gentoo.org> wrote:
> People are encouraged to provide a prototype implementation of such
> eclass in the previously mentioned bug report.
>
Ok, lets discuss the eclass approach here. The 4 variables we want to
deal with are:
XDG_DATA_HOME
XDG_CONFIG_HOME
XDG_CACHE_HOME
XDG_RUNTIME_DIR
I see basically 3 options:
Option 1: Create directories in ${T} and set the XDG variables to
these directories.
This is the approach used by gnome2-utils.eclass
(gnome2_environment_reset). This would need to be done in a "src"
phase so that the directories can be created with the right
permissions and owner. The src_prepare or src_configure phase would
work best here.
The new eclass would simply define a function that creates the
directories and exports the XDG variables, much like
gnome2_environment_reset.
Option 2: Set the variables to ${T}
This makes the timing a bit less important since we are not creating
new directories and do not need to worry about permissions so much. I
think this still needs to be done in a phase function to ensure that
${T} is defined. However, this does not really work for
XDG_RUNTIME_DIR.
This would be implemented the same way as option 1, but without the mkdir call.
Option 3: Unset the variables
This should cause applications to default to locations under ${HOME}.
This could be done in global scope (unless I am overlooking something
in PMS), and so it would not require consumers to invoke anything
explicitly.
The eclass would basically be one unset statement.
Thoughts? I am leaning toward option 3, but if someone knows a reason
that will not work please speak up.
