bug#50789: syncthing-gtk creates autostart file with wrong bin

[Liliana Marie Prikler]

Hi,

Am Donnerstag, den 30.09.2021, 19:29 +0000 schrieb John Kehayias:
> Hello,
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Monday, September 27th, 2021 at 5:23 PM, Liliana Marie Prikler
> wrote:
> 
> > Hi,
> > 
> > Am Montag, den 27.09.2021, 19:04 +0000 schrieb John Kehayias:
> > 
> > > [...]
> > > 
> > > 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.
> > 
> > Unless you are running a dedicated desktop file/autostart editor
> > like alacarte or whatever gnome-tweaks has going for it, writing to
> > .config/autostart is not reasonable behaviour.
> > 
> 
> Sorry, I don't understand this comment. I think this is just the XDG
> specification, user autorun desktop files go in ~/.config/autostart.
> If a program wants to autostart (e.g. user enables the option) this I
> think is the expected and conformant behavior. I see many programs
> doing this (and is where you'd write if you want to change the per-
> user behavior of something in the system autostart, which might also
> be relevant). Anyway, we are getting sidetracked and that's not
> important for the matter at hand, I don't think.
Just because many programs do this doesn't mean they have a good
rationale to do so.  Managing autostarts joins the ranks of having an
updater for the program itself and messing with context menus or
mimetype associations.  This is not the Microsoft OS, we have better
ways of managing things here.

> > > 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
> > 
> > The "full path" desktop files used in Guix do have some advantages.
> > Also, on other distros when using stuff like systemd in a similar
> > manner to shepherd, you have full paths again.
> > 
> > > 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?
> > 
> > I think upstream as good reasons to use full paths, e.g. to prevent
> > the wrong syncthing from being used when there are two in /usr and
> > /usr/local. Were Guix to police upstream on this matter, the
> > decision would clearly be to make this feature optional at the
> > click of a button – and not one that annoyingly pops up if Icecat
> > is not your default browser, if you understand what I'm trying to
> > say.
> > 
> 
> So then I think we end up wanting to patch syncthing-gtk to create
> something like Exec=/path/to/profile/bin/syncthing-gtk I'm not sure
> off the top of my head how to do that (without ending up as it
> currently does with the direct /gnu/store/.../.syncthing-gtk-real
> since that is what the program will see as the origin of the
> process). I can take a look if no one has the Python incantation
> ready. Or else default to using $PATH and/or which; probably the
> right thing most of the time but I'm not sure.
As I stated initially you could hardcode the store path to syncthing-
gtk in its stead but it's still a store path in the end.  It must go
stale by design.  The only reasonable thing is to not install the file
and instead give users the tools to do so on their own.

Regards