GNU bug report logs - #25966
Fix bug 25957 and updates gitolite

Previous Next

Full log

Message #34 received at 25966 <at> debbugs.gnu.org (full text, mbox):

From: Clément Lassieur <clement <at> lassieur.org>
To: ng0 <contact.ng0 <at> cryptolab.net>
Cc: 25966 <at> debbugs.gnu.org
Subject: Re: bug#25966: [PATCH 2/2] gnu: gitolite: Fix shebangs in hooks.
Date: Mon, 13 Mar 2017 15:30:01 +0100

ng0 <contact.ng0 <at> cryptolab.net> writes:

> On 17-03-05 16:24:14, Clément Lassieur wrote:
>> contact.ng0 <at> cryptolab.net writes:
>> 
>> > +                  (add-before 'install 'fix-hooks-shebangs
>> > +                    (lambda* (#:key inputs #:allow-other-keys)
>> > +                      (let ((perl (string-append (assoc-ref inputs "perl")
>> > +                                                 "/bin/perl")))
>> > +                        ;; The files in 'lib/Gitolite/Hooks' keep references to
>> > +                        ;; '/usr/bin/perl', without this fix it is impossible to
>> > +                        ;; to run gitolite in production.
>> > +                        (substitute* (find-files "src/lib/Gitolite/Hooks" ".*")
>> > +                          (("/usr/bin/perl")
>> > +                           perl))
>> > +                        #t)))
>> 
>> This patch introduces references to the store in files installed by
>> "gitolite setup" command.  Those files are installed once and for all.
>> So for example .gitolite/hooks/common/update's shebang is
>> #!/gnu/store/vcjvzmdy5091bklv73rx9nc0yvlk12yv-perl-5.24.0/bin/perl.  But
>> then what happens when perl is upgraded, and Guix garbage collected?  My
>> understanding is that the shebang won't work anymore, and gitolite will
>> be broken.
>> 
>> One can use instead special-files-service-type, which allows to have
>> /usr/bin/perl working.  But it won't work anymore with this patch.
>> 
>> I suggest we revert it, but I might be wrong.  WDYT?
>
> I wanted a solution which works. I didn't consider this until it was
> merged in (see my last reply). I don't think special-file-types are
> a solution, I want this to work out of the box so that a service I want
> to write for gitolite will work.
> It can be a solution if it would work with the service and when it will
> be documented as a requirement for gitolite. The off-the-shelves status
> of gitolite is broken, you are not informed about these shebangs..

This solution works right now, but later, when perl is garbage
collected, it won't work anymore.  And this is worse that just not
working, because things may already be in production when the bug
appears.

The special-files-service-type workaround has the benefit of being
stable: while the user doesn't change her configuration, it will work.
Even though it does not work "out of the box".

So once again, I suggest we revert it.  Please could someone else
comment on this?

(BTW, when this is reverted, users who did run "gitolite setup" with
this patch applied will still have the bug: they'll have to fix it
manually.  So the sooner the better.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.