From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Griffin Subject: Re: [PATCH] gnu: password-store: Wrap PATH. Date: Fri, 29 Jul 2016 09:27:26 -0500 Message-ID: <1469802446.294760.680423961.0E2B23C1@webmail.messagingengine.com> References: <1469751624.114434.679895025.599AB6DD@webmail.messagingengine.com> <1469752717.117537.679907329.010AA3BD@webmail.messagingengine.com> <871t2c7qy0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT8lO-0005WP-1E for guix-devel@gnu.org; Fri, 29 Jul 2016 10:27:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bT8lJ-00041X-Ut for guix-devel@gnu.org; Fri, 29 Jul 2016 10:27:45 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Thompson, David" , Mathieu Lirzin Cc: guix-devel On Fri, Jul 29, 2016, at 09:02 AM, Thompson, David wrote: > Sorry I'm late, but I don't think this is the right fix. Wrapping > programs should only be considered after other options are exhausted. > The correct fix is to patch the source directly to refer to > executables by their absolute path. Why wasn't it done this way? Mostly because it would be a lot of on-going work every time the package is updated. As a shell script, it invokes an external tool nearly every other line. If you look at the discussion that happened in February when the package was first added [1], Jessica (the original packager) was really discouraged by the prospect of patching every invocation of an external tool. She also tried to submit changes upstream so that kind of work wouldn't be necessary, but upstream wasn't very receptive to the idea. In the end, the package was just committed to Guix in a broken state. Another approach I considered was adding a bunch of shell aliases to the top of the script pointing to the Guix store. That makes the problem a lot more tractable than replacing every external invocation, but it's still kinda complicated and it still requires finding every single program that gets called and keeping it up to date with new releases. So even if all upstream does is use another program from coreutils, the fix would be out-of-date again. [1]: https://lists.gnu.org/archive/html/guix-devel/2016-02/msg01310.html -- Alex Griffin