Hi everyone, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 25th, 2021 at 3:02 AM, Liliana Marie Prikler wrote: > I think the answer to that one is fairly simple. Guix should provide a > mechanism to generate/link autostart services, ideally via (guix home), > which will be upstreamed soon (idk if it has one such service already, > just throwing it out there). However, the preferred solution is to not > bother with autostart at all and instead use shepherd to manage user > services – there is a tradeoff to be made between those management > styles somewhere. > I agree we can have a better "Guix way" of doing autostart, documented with examples (perhaps a Cookbook chapter on Desktop usage of Guix). User run shepherd works, at least for some basic background services I run. I don't think it is as documented or as fleshed out as XDG autostart stuff. I too am interested in guix home (just merged!) and will take a look at that. But back to the matter at hand. Medium to long-term I support better Guix services for autostart, but that doesn't address the problem of having packages run as intended by upstream, at least with reasonable expectations. I think this is expected and reasonable behavior, that a program can create a proper .desktop file in Guix. Looking at another non-Guix system, the autostart files I have in ~/.confg/autostart mostly (syncthing-gtk being the main exception) use just Exec=program-name I see this mostly true for /etc/xdg/autostart as well (non-Guix system). So I think this is an easy and typical behavior we can implement. In this case patching syncthing-gtk to produce Exec=syncthing-gtk. Perhaps upstream would consider it as well, unless they have good reason for a full path here, as opposed to other programs. (Upstream is a bit quiet in activity though.) What do we think? John
