From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68807: 29.1; Can bindir used for emacsclient(-mail).desktop in Makefile.in be removed? Date: Tue, 30 Jan 2024 14:19:42 +0200 Message-ID: <86plxj2eu9.fsf@gnu.org> References: <87eddzlpan.fsf@linj.tech> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11507"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68807@debbugs.gnu.org To: Lin Jian Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 30 13:21:18 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rUn77-0002jb-5p for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Jan 2024 13:21:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUn6t-0001N0-90; Tue, 30 Jan 2024 07:21:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUn6l-0001Ih-4S for bug-gnu-emacs@gnu.org; Tue, 30 Jan 2024 07:20:56 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rUn6j-00070a-Pr for bug-gnu-emacs@gnu.org; Tue, 30 Jan 2024 07:20:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rUn6s-0007fy-BK for bug-gnu-emacs@gnu.org; Tue, 30 Jan 2024 07:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Jan 2024 12:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68807 X-GNU-PR-Package: emacs Original-Received: via spool by 68807-submit@debbugs.gnu.org id=B68807.170661720529425 (code B ref 68807); Tue, 30 Jan 2024 12:21:02 +0000 Original-Received: (at 68807) by debbugs.gnu.org; 30 Jan 2024 12:20:05 +0000 Original-Received: from localhost ([127.0.0.1]:34512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rUn5w-0007eW-VK for submit@debbugs.gnu.org; Tue, 30 Jan 2024 07:20:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rUn5u-0007dy-VF for 68807@debbugs.gnu.org; Tue, 30 Jan 2024 07:20:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUn5f-0006eS-MF; Tue, 30 Jan 2024 07:19:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bXq6Q5BsmSwNeMa7eZmAqzm4GhHUeklZA7sbz6k7JE8=; b=Ly6fm+pJmj1A hTVUyukH8GvMZZz+eEZ+CQl1185vscqFrRV5fIHkKuMMMyHblsrGkhtZdfwjlC03EfJ2jTek6u+/n HUu6icAVISUPwcH11r+Dkr1Yc9SY2qj2tS4/hP6WmHJx47UOUJKgrR+JK9d78biIAwH2z97Q9kusa LvvZpjXnuX7FFPPgXq8e9oolLmd0ItkhIu/84tBVElYSSEeIhR3z2/msm8DhHXJSRH5+rVSSSDlle 1vbBHw3ahVAYoPGplkMUc45wXpM04OaO0BgWvuzDAXU7aAiG8G5Cdk83+8rp13qkFrCBAAWP2DWNS h9vncF2HQ3DGdhhZKvJtnw==; In-Reply-To: <87eddzlpan.fsf@linj.tech> (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279168 Archived-At: > 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" > > 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.