DEs probably shouldn't link /share

[michaelpj]

Issue description

A lot of the DEs (gnome, lumina, lxqt, mate, plasma5) put /share into environment.pathsToLink. While this is a reasonable thing to want, really the responsibility for linking relevant paths should belong with modules associated with those paths. e.g. the SDDM modules should link /share/sddm. DEs should only link for the applications they're responsible for (e.g. all the KDE apps in plasma5).

As it is, if a package only works properly because it's covered by the blanked linking of /share, it won't work in a DE that doesn't do this or without a DE. So it masks problems.

However, getting rid of it may be painful as it will likely reveal many such problems.

[michaelpj]

For example, here are the things in /run/current-system/sw/share that are present in my system with KDE but not without:

appdata
color-schemes
config.kcfg
GConf
gir-1.0
gnome-vpn-properties
gsettings-schemas
kconf_update
kde4
kdevappwizard
kf5
khotkeys
knotifications5
konqsidebartng
kpackage
kstyle
ksysguard
kwin
locale
metainfo
nix
plasma
solid
sounds
vala
wallpapers
X11
aclocal
alsa
augeas
avahi
awk
consolefonts
consoletrans
cups
emoticons
evince
factory
fwupd
gettext
git
git-core
git-gui
gitk
help
initramfs-tools
katepart5
kcm_componentchooser
kcm-gtk-module
kcmkeyboard
kcmkeys
kcm_kscreen
kcmmouse
kcm_networkmanagement
kcm_phonon
kcmsolidactions
kcmusb
kcmview1394
kcontrol
kded_kscreen
kdisplay
keymaps
kfontinst
kgamma
khelpcenter
kio_bookmarks
kio_desktop
kio_docfilter
kio_info
kmenuedit
konqueror
konsole
konversation
ksmserver
ksplash
kwincompositing
libvirt
media-player-info
okular
pkgconfig
plymouth
pulseaudio
qemu
QtCurve
remoteview
spotify
systemd
systemsettings
tabset
texinfo
thumbnailers
tlp-pm
unimaps
vim
vlc
wayland-sessions
xml
xsessions
yakuake
zfs
zsh-5.5.1

Obviously not exhaustive, but it's a lot of stuff.

[teto]

As an i3 user, I support the initiative. How to proceed then ? should we move environment.pathsToLink = [ "/share" ]; to the modules. Can't it be a problem for packages without a module ?

[jtojnar]

Ideally, packages should not rely on global state. If they do, fix should be attempted first. See deadbeef, for an example how to how to use plug-ins without global state.

[jtojnar]

Looking at https://www.freedesktop.org/wiki/Specifications/, we need at least sounds and metainfo modules. color might be also nice.

[michaelpj]

I think packages should only link paths if they expect contributions from other packages at runtime, otherwise they shouldn't. It would probably help to make the description of pathsToLink to be a bit more prescriptive about what you should and shouldn't link.

should we move environment.pathsToLink = [ "/share" ]; to the modules

We should be moving environment.pathsToLink = [ "/share/my/specific/subfolder" ]; to the modules where possible, yes.

We should probably have a more general AppStream module than just metainfo, there is also stuff that goes in app-info and some other places.

I think we also want a gtk module, and maybe something for gsettings-schemas?

[jtojnar]

I think packages should only link paths if they expect contributions from other packages at runtime, otherwise they shouldn't.

Indeed – packages should be able to load their own data from the prefix that was set during compilation. Only packages that need to be loaded by many other apps should be linked to system path. It might be fine to use global plug-in directory for packages that support plug-ins temporarily, but eventually, they should be ported to a wrapper with symlinkJoin like e.g. deadbeef.

We should probably have a more general AppStream module than just metainfo, there is also stuff that goes in app-info and some other places.

Yes, the AppStream specification has a legacy path that would need to be supported as well.

I think we also want a gtk module, and maybe something for gsettings-schemas?

Those are not a Freedesktop standard but, you are right, we might want to support them. Though on the latter, I keep alternating between accepting that schemas were designed to be global data, and my hate of global state and wanting to eliminate it.

Also, this issue seems to be missing a link to the original freedesktop module: #45058

[michaelpj]

Yeah, I think we should have modules for stuff that is global state, regardless of whether we like it or not. At the moment we're just hackily handling it elsewhere.

One thing I don't like about this whole situation is that it's done with nixos modules so we end up with differences to what gets installed if you use nix-env. But that's another kettle of fish.

[michaelpj]

I've become much more ambivalent about this. Wanting additional directories in /share is something that you want when you install a program that needs them. At the moment, every such program needs to have its own nixos module.

Given that /share is basically a bin of implicit system dependencies, maybe we should just link the whole thing by default. This is basically what we do for user profiles in nix-env, and I've never heard anyone complain.

[jtojnar]

My main point is that if applications rely on their data being linked into a profile, they may subtly break when the app is not installed – for example, when running the built expression from /nix/store.

[michaelpj]

Hm, that does seem like a good reason to at least wrap the program with a local extension of XDG_DATA_DIRS. But when it is installed in a profile, then it's annoying that it won't pick up other data files unless we write a module for it.

[jtojnar]

Well, if it expects data from other packages, it should accept them as argument, see, for example, https://github.com/NixOS/nixpkgs/blob/e7ff7b93180b5dc3669c8c862fd78d490115a7f0/pkgs/applications/graphics/gimp/wrapper.nix

[jtojnar]

For GNOME:

• share/gnome-control-center/keybindings

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/out-share-linked-with-nix-profile-install-but-not-otherwise/27561/1

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-set-up-a-gtk3-theme-thats-not-in-the-nix-pkgs/28969/3

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/missing-links-in-run-current-system-sw-share/42804/2