From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Lirzin Subject: Re: [PATCH] gnu: password-store: Wrap PATH. Date: Fri, 29 Jul 2016 18:57:37 +0200 Message-ID: <87oa5gcrge.fsf@gnu.org> References: <1469751624.114434.679895025.599AB6DD@webmail.messagingengine.com> <1469752717.117537.679907329.010AA3BD@webmail.messagingengine.com> <871t2c7qy0.fsf@gnu.org> <1469802446.294760.680423961.0E2B23C1@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTB6a-0002EL-4z for guix-devel@gnu.org; Fri, 29 Jul 2016 12:57:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTB6U-00027T-Eb for guix-devel@gnu.org; Fri, 29 Jul 2016 12:57:47 -0400 In-Reply-To: <1469802446.294760.680423961.0E2B23C1@webmail.messagingengine.com> (Alex Griffin's message of "Fri, 29 Jul 2016 09:27:26 -0500") 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: Alex Griffin Cc: guix-devel Alex Griffin writes: > 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. Sorry for not letting you the time to respond. >> 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 This makes sense to me. -- Mathieu Lirzin