From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 2EBD9138A1F for ; Wed, 29 Jan 2014 05:44:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C0E6EE0ACF; Wed, 29 Jan 2014 05:44:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BE9B4E0AB6 for ; Wed, 29 Jan 2014 05:44:46 +0000 (UTC) Received: from android-dca4458af011f6fa.home (unknown [96.241.16.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id BF37D33F80A for ; Wed, 29 Jan 2014 05:44:45 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: References: <20140125221628.26f3aa96@pomiot.lan> <20140126204926.33f2baef@googlemail.com> <20140126213527.1f5f6192@googlemail.com> <20140126225959.6f17bf8a@pomiot.lan> <20140126220347.720b12ed@googlemail.com> <20140127011054.2038.qmail@stuge.se> <1390863743.4662.7.camel@kanae> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----6OEBMI17RDVZO73YOG6CCM4DZGIO4Y" Content-Transfer-Encoding: 8bit Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment From: Alexandre Rostovtsev Date: Wed, 29 Jan 2014 00:44:40 -0500 To: gentoo-dev@lists.gentoo.org Message-ID: X-Archives-Salt: 6f65ea65-e15d-4a02-a003-f354f9d7392c X-Archives-Hash: 40b02aa522ea4c15df64a85866f4244c ------6OEBMI17RDVZO73YOG6CCM4DZGIO4Y Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On January 28, 2014 12:03:04 PM EST, Mike Gilbert wrote: >Option 3: Unset the variables > >This should cause applications to default to locations under ${HOME}. Only those applications that properly comply with standards :) For instance, glib did not start respecting ${HOME} until version 2.36 if I remember right; before that, unset XDG_* variables would cause g_get_user_cache_dir() etc. to fall back to something under /root/ no matter where ${HOME} pointed. Which is the main reason why gnome2_environment_reset() was created. ------6OEBMI17RDVZO73YOG6CCM4DZGIO4Y Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On January 28, 2014 12:03:04 PM EST, Mike Gilbert <floppym@gentoo.org> wrote:
On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue <eva@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.

------6OEBMI17RDVZO73YOG6CCM4DZGIO4Y--