DEs probably shouldn't link `/share`

michaelpj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

michaelpj commented 5 years ago

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 commented 5 years ago

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: https://github.com/NixOS/nixpkgs/pull/45058

michaelpj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

For GNOME:

share/gnome-control-center/keybindings

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

Search for maintainers and people that previously touched the related code and @ mention them in a comment.
Ask on the NixOS Discourse.
Ask on the #nixos channel on irc.freenode.net.

nixos-discourse commented 1 year ago

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 commented 1 year ago

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 commented 4 months ago

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

NixOS / nixpkgs

DEs probably shouldn't link `/share` #47173

Issue description