From: John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: 50789@debbugs.gnu.org, Leo Famulari <leo@famulari.name>
Subject: bug#50789: syncthing-gtk creates autostart file with wrong bin
Date: Thu, 30 Sep 2021 19:29:48 +0000 [thread overview]
Message-ID: <FmxWeSV7EMhnmSIkVby_0QbeESPcBUPpZbJoMR_SZ0i7RBF5O9FmIlfcq352Jh168O4tswcXhSuSdMBM55Bzqbe2kDsNKnmepbBSPpbuYlo=@protonmail.com> (raw)
In-Reply-To: <0ae4d2bfcce16f79680321817ac9e55a380dd0bd.camel@gmail.com>
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.
> > 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.
John
next prev parent reply other threads:[~2021-09-30 19:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 21:33 bug#50789: syncthing-gtk creates autostart file with wrong bin John Kehayias via Bug reports for GNU Guix
2021-09-24 22:55 ` Liliana Marie Prikler
2021-09-24 23:15 ` Leo Famulari
2021-09-25 0:45 ` John Kehayias via Bug reports for GNU Guix
2021-09-25 7:02 ` Liliana Marie Prikler
2021-09-27 19:04 ` John Kehayias via Bug reports for GNU Guix
2021-09-27 21:23 ` Liliana Marie Prikler
2021-09-30 19:29 ` John Kehayias via Bug reports for GNU Guix [this message]
2021-09-30 20:00 ` Liliana Marie Prikler
2021-09-30 20:13 ` John Kehayias via Bug reports for GNU Guix
2021-10-01 7:44 ` Liliana Marie Prikler
2022-01-05 19:31 ` John Kehayias via Bug reports for GNU Guix
2022-01-05 21:13 ` Leo Famulari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='FmxWeSV7EMhnmSIkVby_0QbeESPcBUPpZbJoMR_SZ0i7RBF5O9FmIlfcq352Jh168O4tswcXhSuSdMBM55Bzqbe2kDsNKnmepbBSPpbuYlo=@protonmail.com' \
--to=bug-guix@gnu.org \
--cc=50789@debbugs.gnu.org \
--cc=john.kehayias@protonmail.com \
--cc=leo@famulari.name \
--cc=liliana.prikler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).