Re: [gentoo-dev] Dealing with XDG directories in ebuild environment

[Mike Gilbert]

On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue <eva@g.o> 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.