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

2014-01-29 Thread Jan Matejka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What's the point of having nonempty XDG_ variables in ebuilds? Use of these variables is scoped to user applications that use these in runtime, therefore I see no business for them in package (de)installation and it should be ok for portage to

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

2014-01-29 Thread Alexandre Rostovtsev
On Wed, 2014-01-29 at 09:58 +0100, Jan Matejka wrote: What's the point of having nonempty XDG_ variables in ebuilds? One big reason is FEATURES=test. Test suites for freedesktop-compliant programs that actually run the program are likely to fail if XDG_* directories are resolved as something

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

2014-01-29 Thread Mike Gilbert
On Wed, Jan 29, 2014 at 1:37 AM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: [Replying again since my mailer messed up my original message.] On Tue, 2014-01-28 at 12:03 -0500, Mike Gilbert wrote: Option 3: Unset the variables This should cause applications to default to locations under

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

2014-01-28 Thread Mike Gilbert
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

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

2014-01-28 Thread Alexandre Rostovtsev
On January 28, 2014 12:03:04 PM EST, Mike Gilbert flop...@gentoo.org 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}

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

2014-01-28 Thread Alexandre Rostovtsev
[Replying again since my mailer messed up my original message.] On Tue, 2014-01-28 at 12:03 -0500, Mike Gilbert wrote: 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

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

2014-01-27 Thread Gilles Dartiguelongue
Le lundi 27 janvier 2014 à 02:10 +0100, Peter Stuge a écrit : here any other solution for users than fixing the ebuilds and/or eclass(es)? Any dev is supposed to know if his/her package complies to XDG specifications, easy enough to figure out in most cases. Like other packages affected by

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

2014-01-26 Thread Alec Warner
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

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

2014-01-26 Thread Ciaran McCreesh
On Sun, 26 Jan 2014 12:43:37 -0800 Alec Warner anta...@gentoo.org wrote: I don't buy that. The behavior appears to be currently undefined. Changing it to different undefined behavior is allowed. The point of undefined behaviour is that anything that is relying upon undefined behaviour doing a

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

2014-01-26 Thread Alec Warner
On Sun, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 26 Jan 2014 12:43:37 -0800 Alec Warner anta...@gentoo.org wrote: I don't buy that. The behavior appears to be currently undefined. Changing it to different undefined behavior is allowed. The

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

2014-01-26 Thread Michał Górny
Dnia 2014-01-26, o godz. 21:35:27 Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a): On Sun, 26 Jan 2014 13:21:44 -0800 Alec Warner anta...@gentoo.org wrote: Sorry, I work on Portage. What I'm saying is that We are free to change the behavior of *portage* now; rather than waiting

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

2014-01-26 Thread Ciaran McCreesh
On Sun, 26 Jan 2014 22:59:59 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-01-26, o godz. 21:35:27 Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a): On Sun, 26 Jan 2014 13:21:44 -0800 Alec Warner anta...@gentoo.org wrote: Sorry, I work on Portage. What I'm saying is that

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

2014-01-26 Thread Mike Gilbert
On Sun, Jan 26, 2014 at 5:03 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 26 Jan 2014 22:59:59 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-01-26, o godz. 21:35:27 Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a): On Sun, 26 Jan 2014 13:21:44 -0800

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

2014-01-26 Thread Peter Stuge
Mike Gilbert wrote: It would really nice to have a solution for the few users who do have this set that does not involve adding code to random eclasses, or leaving things broken for X months/years until all ebuilds can be bumped to EAPI 6. Is there any other solution for users than fixing the

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

2014-01-25 Thread Mike Gilbert
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

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

2014-01-25 Thread Pacho Ramos
El sáb, 25-01-2014 a las 11:13 -0500, Mike Gilbert escribió: 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

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

2014-01-25 Thread Michał Górny
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.

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

2014-01-25 Thread Mike Gilbert
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

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

2014-01-25 Thread Mike Gilbert
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