search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.35k stars 13.59k forks source link

Tracking: remove Exec=<absolute path> in desktop entries #308324

Open Aleksanaa opened 4 months ago

Aleksanaa commented 4 months ago

Most upstream provided or auto generated desktop entries uses Exec=foo instead of Exec=$out/bin/foo. But when manually modifying or creating desktop entries, Exec is often set to an absolute path, like $out/bin/foo, which seems reasonable.

However, applications that are set to be launched when login, by xdg autostart, will have their desktop entries moved to ~/.config/autostart. This will cause a problem: when users remove the package from their configuration, they will be surprised to find that the desktop file will still run the next time they log in, because the Exec in it remains valid, unless they manually remove the desktop entry or perform garbage collection.

Another problem that can arise with Exec=$out/bin/foo is that when people use symlinkJoin to wrap a package, they have to rewrite a desktop file, as the old one still points to the unwrapped binary.

I would like to open an issue here to first discuss whether we should set Exec=foo instead of Exec=$out/bin/foo. If this is the case, I'll rename it to Tracking: ....

Thanks @VergeDX for reporting the issue and @OPNA2608 for pointing out the case, and @getchoo for giving me the inspiration in https://github.com/NixOS/nixpkgs/pull/308113#discussion_r1585819842 😄

ping @jtojnar for opinions

Add a :+1: reaction to issues you find important.

jtojnar commented 4 months ago

Yeah, we generally do not want absolute paths in application launcher desktop files precisely for that reason. All methods that install a package so that the launcher is XDG_DATA_DIRS will also put the programs on PATH so having to do a PATH lookup is not an issue.

The only potentially problematic case I can imagine is a GUI app package with a bin output. In that case installing <package> will only link the bin output but the launcher in out would not be installed but that is really the opposite issue. We could fix that by moving share/applications to ${!outputBin} in multiple-outputs.sh hook but it is probably extremely rare anyway.

Aleksanaa commented 4 months ago

The only potentially problematic case I can imagine is a GUI app package with a bin output. In that case installing <package> will only link the bin output but the launcher in out would not be installed but that is really the opposite issue. We could fix that by moving share/applications to ${!outputBin} in multiple-outputs.sh hook but it is probably extremely rare anyway.

In this case having bin output is generally bad for these packages. Even if we install the desktop entry, there are still icons and so on.

Aleksanaa commented 4 months ago

Still more opinions are appreciated!

Aleksanaa commented 4 months ago

I've seen a seemingly valid reason to use store path:

https://github.com/NixOS/nixpkgs/blob/58a1abdbae3217ca6b702f03d3b35125d88a2994/pkgs/applications/misc/redshift/default.nix#L80-L92

Unfortunately, the user who wrote this seems no longer active on GitHub.

Now we have a problem. God knows why those packages that specifically replace Exec=foo with Exec=$out/bin/foo do this (most even without a comment) ? ?

Aleksanaa commented 4 months ago

These are the result of grep -rl '\.desktop' pkgs | xargs grep -l 'Exec=$out'. This of course does not include packages that use makeDesktopItem.

SuperSandro2000 commented 4 months ago

In Plasma 5 I often observed that the start menu after a rebuild would still start the program from the old generation. I didn't notice that on Plasma 6 yet but maybe it is just coincidence and I didn't notice.

OPNA2608 commented 4 months ago

I would like to add that there are other desktop file keys that have the ability to hold an absolute path, both standardised (Icon) and custom (X-Lomiri-Splash-Image).

I think that could lead to icons of copied desktop files going missing, if the store path they originally referenced gets GC'd. More of a cosmetic issue though.

One instance I'm aware of where an absolute icon path is required, for bug workaround reasons I haven't fully understood yet:

https://github.com/NixOS/nixpkgs/blob/bafcff9b1556f7e06399104d99768aa0f80030e5/pkgs/desktops/lomiri/applications/morph-browser/default.nix#L59-L65

tomodachi94 commented 4 months ago

@OPNA2608: consider filing an issue upstream.

Pandapip1 commented 1 month ago

Another reason to not use absolute paths: security wrappers! If a program needs certain capabilities, then using an absolute path in Exec will mean that the security wrapper isn't run.