Subject: bug#68807: 29.1; Can bindir used for emacsclient(-mail).desktop in Makefile.in be removed?

From: Eli Zaretskii <[email-masked]>
Date: Tue, 30 Jan 2024 14:19:42 +0200

> Date: Tue, 30 Jan 2024 06:34:27 +0800
> From:  Lin Jian via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> In Makefile.in, bindir is used for the Exec key of emacsclient.desktop
> and emacsclient-mail.desktop.

Yes, because the Emacs's upstream installation procedure installs
emacsclient in ${bindir}.  So "our "make install" wants to make sure
the desktop file will reference the correct emacsclient, not the one
found first on PATH.

> I am not sure why bindir is used in the first place.  However, I think
> bindir for these two files is not necessary. The reasons are as follows:
> 1. According to the specification[1], it is valid to specify the
> executable program with the name of the executable only.  In this case,
> the executable is looked up in the $PATH environment variable used by
> the desktop environment.
> 2. emacs.desktop does not use bindir.  Instead, it uses only the name of
> the executable, i.e., emacs.  If emacs can be found in $PATH, then so
> can emacsclient because they are installed into the same directory.
> 
> Stopping using bindir for these two files makes Makefiles.in more
> consistent and can ease the work of downstream distribution Nixpkgs.  In
> Nixpkgs, users declaratively specify Elisp packages they want and a
> wrapped Emacs with those packages is generated.  Then, users only use
> the wrapped Emacs.  If bindir is used for these two desktop files, then
> their Exec key points to the origin Emacs instead of the wrapped one.
> Of course, the Exec key can be changed to point to the wrapped Emacs
> during the wrapping process.  However, I think it is better to just
> remove bindir.

My understanding is that you are asking this because some downstream
distro will find it more convenient for its users.  If so, why cannot
the distro modify the top-level Makefile.in according to what you
prefer?  There's no need to propagate distro-specific solutions to the
upstream project, is there?

Since different distros can have different needs and preferences, I'd
prefer not to make changes in the setup of the desktop files we
distribut in favor of one particular distro.  We distribute these
desktop files as a service to distros, and would not want to take
responsibility for understanding the needs of the various distros and
desktops, so as not to increase our maintenance burden in areas where
we have no real domain expertise.

Thanks.