You are not logged in.

#1 2019-06-07 22:16:02

apollo22
Member
Registered: 2018-04-13
Posts: 31

XDG_BASE_DIRECTORY: Official Support ?

I would like to know if Arch Linux OFFICIALLY supports XDG_BASE_DIRECTORY.

If so, is there any written traces of this ?

If not, should it be ? For exemple by adding the defaults in /etc/profile, and making sure packages defaults configuration do not prevent this (for exemple gem).

Last edited by apollo22 (2019-06-07 22:17:51)

Offline

#2 2019-06-08 10:50:23

Omar007
Member
Registered: 2015-04-09
Posts: 296

Re: XDG_BASE_DIRECTORY: Official Support ?

Offline

#3 2019-06-08 11:41:10

ayekat
Member
Registered: 2011-01-17
Posts: 1,331
Website

Re: XDG_BASE_DIRECTORY: Official Support ?

There is no need for "official support", because it's not up to a distribution to support the XDG basedir spec—it's up to the individual applications.

apollo22 wrote:

If not, should it be ? For exemple by adding the defaults in /etc/profile, and making sure packages defaults configuration do not prevent this (for exemple gem).

There is no need to set "defaults"; the specification defines how applications should behave if the environment variables are unset.
And having applications respect the XBDS is not really up to package maintainers (unless they want to do heavy patching, which would go against the core principals of Arch Linux, I believe); if you want gem to properly support the spec, you'll need to ask their developers.


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#4 2019-06-09 08:45:23

apollo22
Member
Registered: 2018-04-13
Posts: 31

Re: XDG_BASE_DIRECTORY: Official Support ?

I believe this is simply documentation, not expressing the official position of Arch Linux.

ayekat wrote:

There is no need to set "defaults"; the specification defines how applications should behave if the environment variables are unset.

Some applications don't respect the default if the environment variables are unset, explicitly setting those variables by default would make it more transparent and send a message that Arch officially supports it.

This "official" support could even go further and implement the various "partial" support methods based on environment variables.

ayekat wrote:

And having applications respect the XBDS is not really up to package maintainers (unless they want to do heavy patching, which would go against the core principals of Arch Linux, I believe); if you want gem to properly support the spec, you'll need to ask their developers.

By default, the configuration in `/etc` explicitly prevents the support of XDG_BASE_DIRECTORY (see Ruby#RubyGems in partial support on the wiki)

Offline

#5 2019-06-09 10:50:37

ayekat
Member
Registered: 2011-01-17
Posts: 1,331
Website

Re: XDG_BASE_DIRECTORY: Official Support ?

apollo22 wrote:

Some applications don't respect the default if the environment variables are unset, explicitly setting those variables by default would make it more transparent

Then those applications simply haven't implemented the specification correctly. That's probably a bug that should be reported. Upstream.

And how does setting the environment variables system-wide make things more transparent? If anything, it would make things less transparent, because now we would sweep those issues under the rug (applications misbehaving with unset XBDS variables would no longer be detected that easily).

This "official" support could even go further and implement the various "partial" support methods based on environment variables.

Applying that list of workaround-hacks on an distro-wide level would mean that Arch now deviates from default upstream behaviour (essentially just because $opinion), which is not in line with Arch's philosophy of packaging software as vanilla as possible.

Don't get me wrong, I agree that it would be nice if applications properly supported the XBDS (even if it has its own list of flaws). But doing downstream-specific hacks is not the way to go.

By default, the configuration in `/etc` explicitly prevents the support of XDG_BASE_DIRECTORY (see Ruby#RubyGems in partial support on the wiki)

Yes, this is a downstream configuration preventing proper usage of the XBDS, and probably merrits a fix.
I don't know Ruby Gems enough to understand what exactly they are trying to work around there, but if you come up with a better way, you could file a bug report for that package (and if you're unrealisticly optimistic, expect your improvement to be applied by the packager).

That being said, even without /etc/gemrc, Ruby Gems still requires the user to set custom environment variables, so a more sustainable approach would be to ask upstream directly to properly support the XBDS.


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#6 2019-06-09 11:04:41

apollo22
Member
Registered: 2018-04-13
Posts: 31

Re: XDG_BASE_DIRECTORY: Official Support ?

ayekat wrote:

And how does setting the environment variables system-wide make things more transparent? If anything, it would make things less transparent, because now we would sweep those issues under the rug (applications misbehaving with unset XBDS variables would no longer be detected that easily).

[...]

Applying that list of workaround-hacks on an distro-wide level would mean that Arch now deviates from default upstream behaviour (essentially just because $opinion), which is not in line with Arch's philosophy of packaging software as vanilla as possible.

[...]

Don't get me wrong, I agree that it would be nice if applications properly supported the XBDS (even if it has its own list of flaws). But doing downstream-specific hacks is not the way to go.

How about adding a package adding a /etc/profile.d/xdg-base-directory.sh, which would be in opt-in rather than a vanilla ? [I can actually make that happen myself through the AUR]

Offline

#7 2019-06-09 11:17:55

ayekat
Member
Registered: 2011-01-17
Posts: 1,331
Website

Re: XDG_BASE_DIRECTORY: Official Support ?

apollo22 wrote:

How about adding a package adding a /etc/profile.d/xdg-base-directory.sh, which would be in opt-in rather than a vanilla ? [I can actually make that happen myself through the AUR]

Feel free to do so. I don't believe this will get adopted into the official repos, though (those variables used to be set system-wide in the past, but that was removed—see FS#31204 for a discussion).


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

Board footer

Powered by FluxBB