-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
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
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
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
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}
[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
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
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
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
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
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
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
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
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
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
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
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.
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
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
19 matches
Mail list logo