On Wed, Jan 29, 2014 at 1:37 AM, Alexandre Rostovtsev
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 ${HOME}.
>>
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 unw
-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 unset
[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
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
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_HOM
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 en
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
On Sun, Jan 26, 2014 at 5:03 PM, Ciaran McCreesh
wrote:
> On Sun, 26 Jan 2014 22:59:59 +0100
> Michał Górny wrote:
>> Dnia 2014-01-26, o godz. 21:35:27
>> Ciaran McCreesh napisał(a):
>> > On Sun, 26 Jan 2014 13:21:44 -0800
>> > Alec Warner wrote:
>> > > Sorry, I work on Portage. What I'm saying
On Sun, 26 Jan 2014 22:59:59 +0100
Michał Górny wrote:
> Dnia 2014-01-26, o godz. 21:35:27
> Ciaran McCreesh napisał(a):
> > On Sun, 26 Jan 2014 13:21:44 -0800
> > Alec Warner wrote:
> > > Sorry, I work on Portage. What I'm saying is that We are free to
> > > change the behavior of *portage* now
Dnia 2014-01-26, o godz. 21:35:27
Ciaran McCreesh napisał(a):
> On Sun, 26 Jan 2014 13:21:44 -0800
> Alec Warner 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 for a new
> > EAPI. If an ebuild needs to def
On Sun, 26 Jan 2014 13:21:44 -0800
Alec Warner 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 for a new
> EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use
> XDG_*, well that is someone else's
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 wrote:
> > I don't buy that. The behavior appears to be currently undefined.
> > Changing it to different undefined behavior is allowed.
>
> The point of u
On Sun, 26 Jan 2014 12:43:37 -0800
Alec Warner 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 particular thing i
On Sat, Jan 25, 2014 at 4:19 PM, Mike Gilbert wrote:
> On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert wrote:
> > On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny wrote:
> >> Dnia 2014-01-25, o godz. 11:13:38
> >> Mike Gilbert napisał(a):
> >>
> >>> It seems having XDG variables like XDG_CONFIG_HOM
On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert wrote:
> On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny wrote:
>> Dnia 2014-01-25, o godz. 11:13:38
>> Mike Gilbert napisał(a):
>>
>>> It seems having XDG variables like XDG_CONFIG_HOME set in the
>>> environment when calling emerge has a tendency to
On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny wrote:
> Dnia 2014-01-25, o godz. 11:13:38
> Mike Gilbert 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 blocki
Dnia 2014-01-25, o godz. 11:13:38
Mike Gilbert 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.
>
> https://bugs.gentoo.org/show_bug.cgi?id=49
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=49
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
20 matches
Mail list logo
