Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
-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
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.
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 ${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
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
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
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} 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
[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
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 e...@gentoo.org Gentoo
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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 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
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
[gentoo-dev] Dealing with XDG directories in ebuild environment
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
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
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.
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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
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 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
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
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
