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

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

[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 see
that several eclasses work around this by setting
XDG_CONFIG_HOME="${T}" or "${T}/.config".

gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.

Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?

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

[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
> 
> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
> that several eclasses work around this by setting
> XDG_CONFIG_HOME="${T}" or "${T}/.config".
> 
> gnome2-utils.eclass takes it a step further and creates empty
> directories for several other XDG variables.
> 
> Is this something we can/should consolidate into some central place?
> Or should I just copy/paste something into distutils-r1.eclass?
> 

Maybe the function cleaning stuff could be added to eutils.eclass and we
would call it from other eclasses/ebuilds. I also wonder if this cleanup
could be done always in a newer eapi since we usually need to add that
fix whenever we suffer the sandbox violation :S (not before)

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Dnia 2014-01-25, o godz. 11:13:38
Mike Gilbert <floppym@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.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=499202
> 
> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
> that several eclasses work around this by setting
> XDG_CONFIG_HOME="${T}" or "${T}/.config".
> 
> gnome2-utils.eclass takes it a step further and creates empty
> directories for several other XDG variables.
> 
> Is this something we can/should consolidate into some central place?
> Or should I just copy/paste something into distutils-r1.eclass?

I'd say portage should kill that as part of sanitizing the environment.
There's no point in reproducing it in random eclasses.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Mike Gilbert]

On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-01-25, o godz. 11:13:38
> Mike Gilbert <floppym@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.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=499202
>>
>> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
>> that several eclasses work around this by setting
>> XDG_CONFIG_HOME="${T}" or "${T}/.config".
>>
>> gnome2-utils.eclass takes it a step further and creates empty
>> directories for several other XDG variables.
>>
>> Is this something we can/should consolidate into some central place?
>> Or should I just copy/paste something into distutils-r1.eclass?
>
> I'd say portage should kill that as part of sanitizing the environment.
> There's no point in reproducing it in random eclasses.
>

I have filed an enhancement request for Portage.

https://bugs.gentoo.org/show_bug.cgi?id=499288

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

[Mike Gilbert]

On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> Dnia 2014-01-25, o godz. 11:13:38
>> Mike Gilbert <floppym@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.
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=499202
>>>
>>> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
>>> that several eclasses work around this by setting
>>> XDG_CONFIG_HOME="${T}" or "${T}/.config".
>>>
>>> gnome2-utils.eclass takes it a step further and creates empty
>>> directories for several other XDG variables.
>>>
>>> Is this something we can/should consolidate into some central place?
>>> Or should I just copy/paste something into distutils-r1.eclass?
>>
>> I'd say portage should kill that as part of sanitizing the environment.
>> There's no point in reproducing it in random eclasses.
>>
>
> I have filed an enhancement request for Portage.
>
> https://bugs.gentoo.org/show_bug.cgi?id=499288

It seems Arfrever beat me to it. However, it looks like it would need
to be an EAPI change, which means quite a long wait.

https://bugs.gentoo.org/show_bug.cgi?id=444568

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Sat, Jan 25, 2014 at 4:19 PM, Mike Gilbert <floppym@gentoo.org> wrote:

> On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> > On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >> Dnia 2014-01-25, o godz. 11:13:38
> >> Mike Gilbert <floppym@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.
> >>>
> >>> https://bugs.gentoo.org/show_bug.cgi?id=499202
> >>>
> >>> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
> >>> that several eclasses work around this by setting
> >>> XDG_CONFIG_HOME="${T}" or "${T}/.config".
> >>>
> >>> gnome2-utils.eclass takes it a step further and creates empty
> >>> directories for several other XDG variables.
> >>>
> >>> Is this something we can/should consolidate into some central place?
> >>> Or should I just copy/paste something into distutils-r1.eclass?
> >>
> >> I'd say portage should kill that as part of sanitizing the environment.
> >> There's no point in reproducing it in random eclasses.
> >>
> >
> > I have filed an enhancement request for Portage.
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=499288
>
> It seems Arfrever beat me to it. However, it looks like it would need
> to be an EAPI change, which means quite a long wait.
>

I don't buy that. The behavior appears to be currently undefined. Changing
it to different undefined behavior is allowed.

If EAPI-NEXT wants to define the behavior of XDG_* then that is fine too,
we will just be ahead of the curve, rather than behind.

-A


>
> https://bugs.gentoo.org/show_bug.cgi?id=444568
>
>

[-- Attachment #2: Type: text/html, Size: 3018 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Sun, 26 Jan 2014 12:43:37 -0800
Alec Warner <antarus@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 particular thing is broken. PMS doesn't
define what happens to XDG_*, so if your ebuilds need a particular
thing done for it then they must be fixed.

Perhaps PMS should be more explicit in stating this -- we lifted the
concept of undefined behaviour from the C and C++ standards, and just
assumed that people would know what it meant. Maybe we need a bit more
text to clear up the misconception we see every now and again that
"undefined" somehow means "it's ok to assume what some version of
Portage happens to do, since the specification doesn't say you can't
do that"...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Sun, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh <
ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 26 Jan 2014 12:43:37 -0800
> Alec Warner <antarus@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 particular thing is broken. PMS doesn't
> define what happens to XDG_*, so if your ebuilds need a particular
> thing done for it then they must be fixed.
>
> Perhaps PMS should be more explicit in stating this -- we lifted the
> concept of undefined behaviour from the C and C++ standards, and just
> assumed that people would know what it meant. Maybe we need a bit more
> text to clear up the misconception we see every now and again that
> "undefined" somehow means "it's ok to assume what some version of
> Portage happens to do, since the specification doesn't say you can't
> do that"...
>

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 can of worms.

-A


>
> --
> Ciaran McCreesh
>

[-- Attachment #2: Type: text/html, Size: 2124 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Sun, 26 Jan 2014 13:21:44 -0800
Alec Warner <antarus@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 for a new
> EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use
> XDG_*, well that is someone else's can of worms.

Changing Portage to hide the issue is a bad idea, since it makes it
harder for developers to notice that that's a problem they need to fix.
Although maybe you could set XDG_* to something that will give a big
noisy sandbox violation for current EAPIs?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Dnia 2014-01-26, o godz. 21:35:27
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> napisał(a):

> On Sun, 26 Jan 2014 13:21:44 -0800
> Alec Warner <antarus@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 for a new
> > EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use
> > XDG_*, well that is someone else's can of worms.
> 
> Changing Portage to hide the issue is a bad idea, since it makes it
> harder for developers to notice that that's a problem they need to fix.
> Although maybe you could set XDG_* to something that will give a big
> noisy sandbox violation for current EAPIs?

Yes, because instantly breaking a few dozen ebuilds in stable tree for
the sake of proving a point is always a good idea.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Sun, 26 Jan 2014 22:59:59 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-01-26, o godz. 21:35:27
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> napisał(a):
> > On Sun, 26 Jan 2014 13:21:44 -0800
> > Alec Warner <antarus@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 for a
> > > new EAPI. If an ebuild needs to define EAPI=eapi-next to
> > > 'correctly' use XDG_*, well that is someone else's can of worms.
> > 
> > Changing Portage to hide the issue is a bad idea, since it makes it
> > harder for developers to notice that that's a problem they need to
> > fix. Although maybe you could set XDG_* to something that will give
> > a big noisy sandbox violation for current EAPIs?
> 
> Yes, because instantly breaking a few dozen ebuilds in stable tree for
> the sake of proving a point is always a good idea.

It's not about proving a point, it's about fixing existing bugs. It's
changing a hard-to-see error into an easy-to-see error, so that it can
be fixed more quickly. This change would introduce no new breakage,
since anything affected by it is already broken.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Gilbert]

On Sun, Jan 26, 2014 at 5:03 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 26 Jan 2014 22:59:59 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>> Dnia 2014-01-26, o godz. 21:35:27
>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> napisał(a):
>> > On Sun, 26 Jan 2014 13:21:44 -0800
>> > Alec Warner <antarus@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 for a
>> > > new EAPI. If an ebuild needs to define EAPI=eapi-next to
>> > > 'correctly' use XDG_*, well that is someone else's can of worms.
>> >
>> > Changing Portage to hide the issue is a bad idea, since it makes it
>> > harder for developers to notice that that's a problem they need to
>> > fix. Although maybe you could set XDG_* to something that will give
>> > a big noisy sandbox violation for current EAPIs?
>>
>> Yes, because instantly breaking a few dozen ebuilds in stable tree for
>> the sake of proving a point is always a good idea.
>
> It's not about proving a point, it's about fixing existing bugs. It's
> changing a hard-to-see error into an easy-to-see error, so that it can
> be fixed more quickly. This change would introduce no new breakage,
> since anything affected by it is already broken.
>

Most people do not have XDG_CONFIG_HOME, etc. set in their
environment, so having the package manager set it to something that
intentionally breaks ebuilds is a step backward for most end users.

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.

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

[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 ebuilds and/or
eclass(es)?

Maybe one way to get things fixed would be to add a QA warning
encouraging users to file bugs?


//Peter

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

[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 environment variables they use
(gstreamer, glib, etc), we just need a sane place to properly reset/set
those to ensure repeatability of builds.

Given current PM behavior, it is not possible to change what is exported
to build environment without an EAPI bump because the potential for
breakage is huge and you do not want to spend your next month building
the tree to build a whitelist of environment variables, right ? Imho,
the best course of action is to move that to an eclass for now.

People are encouraged to provide a prototype implementation of such
eclass in the previously mentioned bug report.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

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

[Mike Gilbert]

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.

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]



On January 28, 2014 12:03:04 PM EST, Mike Gilbert <floppym@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} 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.

[-- Attachment #2: Type: text/html, Size: 2390 bytes --]

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

[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 PMS), and so it would not require consumers to invoke anything
> explicitly.

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.

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

[Mike Gilbert]

On Wed, Jan 29, 2014 at 1:37 AM, Alexandre Rostovtsev
<tetromino@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 ${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.
>
> 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.
>
>

Ah, thank you for that insight.

Ok, so I'm thinking maybe it would be best to combine option 1 and
option 3. We would unset the variables in global scope, and then have
a function that ebuilds or other eclasses could call to basically do
exactly what gnome2_reset_environment does and reset them to some path
under $T.

I'll work on a prototype for that.

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

[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 unset the variables
and if application is using these during build/install (in system
context) it's a problem with the application.

- --
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJS6MKtAAoJEIN+7RD5ejah6GsH+wcuWYyl3Ki3J/U0KT8QTrOx
s5mixaNjrZ6sveU/3dUtCvKz/l9ZyR4YmKcQ8/Syv/UmoGQRdwYs+AgFsmfPPx6Z
N46KK0pg6KAgVpHjJtJ1ZAbKO0tu39dz7c+GimnUYTqjUdrNtSHu4AUiaEQKCBft
DTzD68LGE7lthoXtz1Y5OPjD/U0PXpOowcLo98RSgQnGOggdjBxPNBE05WWVWxM6
9XIKFNdca9sFGBuJQwoXiPNTXxnzizTXnukUgzvuctMg5uPPq2hfKVyktCilslGA
X+JHZ2jT5bzJgeHbJK+6zEoPfjgxrY4fVg2DmLfUmnt7gP8N3wU/6MKILt7CpdM=
=aSXC
-----END PGP SIGNATURE-----

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

[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 unwriteable.

Also, many gnome-related packages have a build system that won't work if
XDG_* variables are wrong. Python packages that use sphinx to generate
API docs at build time will hit a sandbox violation if XDG_CONFIG_HOME
is unwriteable, see https://bugs.gentoo.org/show_bug.cgi?id=499068
I would be astonished if some packages for kde, xfce, and other desktop
environments are not affected as well.

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

[Steven J. Long]

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 can of worms.

Agreed: portage can clear those vars from the env as mgorny stated on the bug,
and an xdg.eclass (or w/e) can setup good defaults for packages which need
them. Presumably it'd be inherited by gnome and kde eclasses, for example,
so most people wouldn't even see it.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Gilles Dartiguelongue]

Le mardi 28 janvier 2014 à 13:11 +0000, Steven J. Long a écrit :
> 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 can of worms.
> 
> Agreed: portage can clear those vars from the env as mgorny stated on the bug,
> and an xdg.eclass (or w/e) can setup good defaults for packages which need
> them. Presumably it'd be inherited by gnome and kde eclasses, for example,
> so most people wouldn't even see it.

Exactly.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo