Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31204 - [libx11] overwrite XDG_CONFIG_HOME and friends

Attached to Project: Arch Linux
Opened by Sébastien Luttringer (seblu) - Monday, 20 August 2012, 02:08 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 26 February 2013, 16:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Eric Belanger (Snowman)
Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No



Files /etc/profile.d/xorg.* overwrite the following environment variables (more or less cleanly):


These variables are overwritten each time a shell is spawned instead of be inherited from correct environment.
The best way (i found) to define those variables is in ~/.pam_environment (read by pam_env).

By example, if i want overwrite my XDG_DATA_HOME to ~/.data, i can put a line in ~/.pam_environment.

These vars should be defined by users to override default locations defined in [1] and not defined to there default by a shell.

I think we should drop these files. Or, at least, check if they already exists before overwrite.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 26 February 2013, 16:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  no more XDG predefinitions for now
Comment by Matthias Dienstbier (fs4000) - Monday, 20 August 2012, 15:48 GMT
Other distributions (at least Fedora and Debian) don't even ship those files. Every program should fall back to the defaults if these variables are unset.
Comment by Pontus Andersson (epontan) - Saturday, 15 September 2012, 18:21 GMT
I am not against the overwriting per se as the user can still overwrite it using .bashrc or similar.
However, if we are going to overwrite the variables lets do the same for XDG_DATA_DIRS and XDG_CONFIG_DIRS.
Now it will add the same dir for every subshell, which is a bit ugly. This is how it looks for me:

% env | grep XDG.\*DIRS
Comment by Sébastien Luttringer (seblu) - Monday, 17 September 2012, 06:27 GMT
This doesn't works for program which doesn't use login shell before be runned. To have the both, we need to have configuration in multiple places (it sucks).
Comment by Greg (dolby) - Saturday, 17 November 2012, 07:14 GMT
+1 on what fs4000 says on comment #1.
When i was talking to some gnome people a while ago they were pretty surprised seeing those variables in my env.
Are they needed?
Comment by Andreas Radke (AndyRTR) - Saturday, 09 February 2013, 14:32 GMT
libx11 1.5.0-2 is now in testing with those profile files removed. Let's test them if everything keeps working as expected.
Comment by Mantas Mikulėnas (grawity) - Saturday, 09 February 2013, 21:49 GMT
Re "These variables are overwritten each time a shell is spawned instead of be inherited from correct environment" – normally, /etc/profile is only read by *login* shells, not *all* shells, so it isn't too different from .pam_environment.

(Still, I agree with the removal – I had a chance to fix a few of my scripts.)
Comment by Eric Belanger (Snowman) - Sunday, 10 February 2013, 20:30 GMT
The libx11 with the removed profiles cause major breakage here.
- liferea and gedit doesn't start: Trace/breakpoint trap (core dumped)
- opening a file in emacs : Trace/breakpoint trap (core dumped)
- icons in system tray are broken (deluge) or too small (quodlibet)

I'm using fvwm FWIW.
Comment by Andreas Radke (AndyRTR) - Monday, 11 February 2013, 05:45 GMT
Then let's blaim your window manager being not XDG/ standard compliant.

We need to decide if we bring the viriables back or leave it up to the users to menage it through the login process.
Opinions welcome.
Comment by Denis Kasak (dkasak) - Monday, 11 February 2013, 12:57 GMT
Since the defaults are always going to be the same, it seems nicer to have the OS/distribution define the variables rather than making each program author define them over and over again (a redunancy which will undoubtedly result in bugs). It would be great if it all worked out of the box with $HOME/.config, $HOME/.local/share, etc, while still having the option to override this. It would be even better if this was mandated by the XDG standards.
Comment by Leonid Isaev (lisaev) - Monday, 11 February 2013, 17:04 GMT
Yes, breaking barebones WM's is expected: you need a proper session manager (link xfce4-session).

Having said that, setting XDG variables on each login is a bad idea. For instance, I have libx11 as a dep on a server which has no Xorg. Why do I need these variables in my env?

If some programs break because of unset XDG vars, the best way to proceed is to copy-paste /etc/profile.d/ in the beginning of your $HOME/.xinitrc.
Comment by Mantas Mikulėnas (grawity) - Monday, 11 February 2013, 17:16 GMT

> For instance, I have libx11 as a dep on a server which has no Xorg. Why do I need these variables in my env?

Because they are not specific to Xorg. For example, on my own machine, XDG_CONFIG_HOME is used by: burp, cower, git, htop, newsbeuter, obnam, pulseaudio, ranger, systemd, transmission-daemon – none of which depend on Xorg.
Comment by Leonid Isaev (lisaev) - Monday, 11 February 2013, 17:56 GMT
Just to be clear, we are talking about per-user XDG settings, not system-wide...

I don't think systemd should care about settings involving $HOME. Git probably needs XDG variables for the per-user gui settings (which I've never used)...
Comment by Mantas Mikulėnas (grawity) - Monday, 11 February 2013, 18:15 GMT

> Just to be clear, we are talking about per-user XDG settings, not system-wide...


> I don't think systemd should care about settings involving $HOME.

The `systemd --user` instance I'm running under my account has every right to look in my $HOME to find my own session services.

> Git probably needs XDG variables for the per-user gui settings (which I've never used)...

No, git keeps its configuration file in $XDG_CONFIG_HOME/git/config as of 1.8.0.

Even if it didn't, one invalid example would not mean all other examples automatically become invalid (which they aren't).
Comment by Eric Belanger (Snowman) - Monday, 11 February 2013, 19:47 GMT
It would be nice to know how many WM are affected by this.

I would tend to say to bring them back. Setting them to sane defaults make sense otherwise we might end up with many users with broken systems. You could check if the XDG_*_HOME variables exist before overwriting them like it was done for the other XDG variables.

I noticed that kdelibs3 also modifies XDG_DATA_DIRS so I might need to do take care of it depending what we decide to do.
Comment by Leonid Isaev (lisaev) - Monday, 11 February 2013, 21:34 GMT
Startxfce4 script seems to handle XDG vars correctly, so xfce4 is not affected
$ gr XDG /usr/bin/startxfce4| gr export
$ gr XDG /etc/xdg/xfce4/xinitrc | gr export
I would also assume that gnome and kde4 are fine (probably {g,k}dm is required though).

Rearding default settings (remember, these are per-user), whouldn't it be logical to set them in /etc/skel/.bash_profile?
Comment by Mantas Mikulėnas (grawity) - Monday, 11 February 2013, 21:53 GMT
> whouldn't it be logical to set them in /etc/skel/.bash_profile?

.bash_profile is too bash-specific. If it was renamed to .profile, it might be better – then it would also be respected by various DEs and other shells, not just bash. For example: <<'EOF'

[ "$XDG_CACHE_HOME" ] || export XDG_CACHE_HOME="$HOME/.cache"
[ "$XDG_CONFIG_HOME" ] || export XDG_CONFIG_HOME="$HOME/.config"
[ "$XDG_DATA_HOME" ] || export XDG_DATA_HOME="$HOME/.local/share"

if [ "$BASH" ] && [ -f ~/.bashrc ]; then
. ~/.bashrc

Comment by Joseph Yaworski (jyaworski) - Monday, 11 February 2013, 22:49 GMT
I'm using KDE launched with KDM, and I needed the file to use Firefox, Seamonkey, etc. after upgrading to libx11 -2 in testing. I'm fine with keeping the file, but is there no other way to solve the issue?
Comment by Maciej Sitarz (macieks2) - Monday, 11 February 2013, 23:16 GMT
My KDE environment was also affected... firefox/thunderbird/chromium dumped cores.

Looks like the cause of the problem is kdelibs3 package which ships /etc/profile.d/

# XDG_DATA_DIRS="/opt/kde/share" gsettings list-schemas
Segmentation fault
# XDG_DATA_DIRS="" gsettings list-schemas; echo $?
# XDG_DATA_DIRS="/usr/share:/opt/kde/share" gsettings list-schemas; echo $?

If only /opt/kde/share is set then all is broken. Maybe that should be removed from kdelibs3 package together with the change in libx11?
Comment by Eric Belanger (Snowman) - Tuesday, 12 February 2013, 02:56 GMT
Maciej: You're correct. That is also the cause of my problems. I'll put a fixed kdelibs3 package in [testing].
Comment by Ng Oon-Ee (ngoonee) - Wednesday, 13 February 2013, 02:07 GMT
On awesomewm here, Xyne's mimeo just stops working due to XDG_{DATA,CONFIG}_DIRS not being set. Adding as a data-point for the discussion.
Comment by Andreas Radke (AndyRTR) - Thursday, 14 February 2013, 05:26 GMT
Any further breakage? Can we move libx11 + kdelibs3 to extra?

I guess that mimeo might need some local changes. I've never used it.
Comment by Ng Oon-Ee (ngoonee) - Thursday, 14 February 2013, 05:53 GMT
mimeo has been fixed to work now, so from that angle no issue
Comment by Sam (smls) - Friday, 15 February 2013, 09:23 GMT
My KDE 4.10 environment (launched with kdm) is still affected.

Firefox core-dumps on start, but when I run the contents of the file in a Konsole window and then execute Firefox from there, it starts fine.
Comment by Andreas Radke (AndyRTR) - Saturday, 23 February 2013, 13:01 GMT
Two ways now possible: move libx11+kdelibs3 without defining the XDG vars. This will lead to broken setups where user set some custom path - we can say your app or desktop is broken - fix it yourself.
Or we bring the vars back in case they are not set at all. Then user setting will append on correct defaults.
Comment by Leonid Isaev (lisaev) - Sunday, 24 February 2013, 18:36 GMT
AFAIU libx11 was setting the defaults, albeit explicitly.

* If user defines his/her own XDG environment, what's the point in setting defaults system-wide in the 1st place?
* The reason why kdelibs3 broke is because the profile script simply set XDG_DATA_DIRS to /opt/kde/... if it's empty, while the correct behavior would have been to set this var as ${default}:/opt/kde/... That was certainly against standards.

I think that the settings in /etc/ must be as generic and minimal and possible, and there is no point in providing settigns which user can easily set in his/her /home. For instance, if the user doesn't want to chase bugs in desktop apps, (s)he can simply set all XDG vars from libx11's profile in .bash_profile or .xinitrc (that's what I did, and none of my programs broke).

So, I'd prefer the 1st path, probably accompanied by a news announcement (I can write a draft if you want)...