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 5BD7E138A1F for ; Tue, 28 Jan 2014 17:03:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0238DE0D5C; Tue, 28 Jan 2014 17:03:08 +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 046DDE0BA7 for ; Tue, 28 Jan 2014 17:03:06 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 2DC6C33EF49 for ; Tue, 28 Jan 2014 17:03:06 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id e14so744144iej.18 for ; Tue, 28 Jan 2014 09:03:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZImepTTlPK/tlr3lhz4zxTb1c6Aba4k/xpQ60iIrSV8=; b=D19rc3z+j6614rAP4ZCcsU6ZRB0/ozJilzTrt/9ogFcdzqWSHLkjgZ1qq4ujvGfKE4 BEjoDet7gB/lc7/KmRMYrvivnW1eKo7IfJSWzQGk1ws8XPvctB1QR4Gl8HsYNRxA9hoK avjK9KVgosvq9V3wiuYSPJSzUqeCiluHrEyDkuPz6yZJTyuC7o3M1cKVYgVwfmvFUgiM wfMHxdZ4MYwiF8cTwmI8rHKHtrelmmS8XuFr2luQei2ehXppEINH32tBe88eaDrDDqCW 1tn2SUa7nul+6dbebpYrZwT1uKcz6UIY31ceKLPnIoVvvRqno0iwA/+5/Mvsmp6RkB0J Iymw== 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 X-Received: by 10.50.28.72 with SMTP id z8mr3756654igg.44.1390928584796; Tue, 28 Jan 2014 09:03:04 -0800 (PST) Received: by 10.64.136.18 with HTTP; Tue, 28 Jan 2014 09:03:04 -0800 (PST) In-Reply-To: <1390863743.4662.7.camel@kanae> 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> Date: Tue, 28 Jan 2014 12:03:04 -0500 Message-ID: Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment From: Mike Gilbert To: Gentoo Dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 73d3f368-8439-4001-81a7-8080ea6a4ceb X-Archives-Hash: c3b5f8a080728da8991af238602bd6b0 On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue 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.