From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ulrich Mueller Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: etags name collision. Date: Tue, 12 Apr 2022 14:50:00 +0200 Message-ID: References: <83k0bv679q.fsf@gnu.org> <20220411154635.qfw2ijpdahiv5ctl@Ergus> <83fsmj62jl.fsf@gnu.org> <20220411161942.xsqr3ekorpm6jf6y@Ergus> <83ee2360aq.fsf@gnu.org> <20220411191933.wyxvmgpyd4hnpfc2@Ergus> <20220411195350.7jhugti3e3vng6yx@Ergus> <835ynf592m.fsf@gnu.org> <20220412111302.ore2hikj4yxftuxz@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40727"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 12 14:51:31 2022 Return-path: Envelope-to: ged-emacs-devel@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 1neFzX-000ASX-0m for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 14:51:31 +0200 Original-Received: from localhost ([::1]:55458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neFzV-0003yr-Lh for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 08:51:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neFyF-0002ML-O7 for emacs-devel@gnu.org; Tue, 12 Apr 2022 08:50:11 -0400 Original-Received: from smtp.gentoo.org ([2001:470:ea4a:1:5054:ff:fec7:86e4]:59679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1neFyD-0000ia-AT; Tue, 12 Apr 2022 08:50:10 -0400 In-Reply-To: <20220412111302.ore2hikj4yxftuxz@Ergus> (Ergus's message of "Tue, 12 Apr 2022 13:13:02 +0200") Received-SPF: pass client-ip=2001:470:ea4a:1:5054:ff:fec7:86e4; envelope-from=ulm@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288299 Archived-At: >>>>> On Tue, 12 Apr 2022, Ergus wrote: >> But then the test should be more specific, and check if there would be a >> file collision at the actual target location (with the name modified by >> --program-transform-name, if applicable). If there's no collision (e.g. >> Emacs ctags has a different name) then Emacs should install it. > If we don't do that with mailutils why should we do it with ctags... > It will be more complex and error prone. Because it's a different problem. The mailutils flag is there because of security concerns with the bundled movemail. There is no file collision in that case, because Emacs doesn't install its movemail program in /usr/bin but in /usr/libexec/emacs/. > I would be even simpler and just add the option --without-ctags to not > build our ctags on demand unconditionally, keeping things as they are > now by default. Right. The test doesn't add much value (if any). > as a plus we could make: --with-ctags=no, to not build; and we could > allow to do things like: --with-ctags=ctags.emacs to explicitly create > it as ctags.emacs... But I am sure such method will break some standard > or development agreement. Way too complicated IMHO.