guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25966: [PATCH 2/2] gnu: gitolite: Fix shebangs in hooks.


From: Clément Lassieur
Subject: bug#25966: [PATCH 2/2] gnu: gitolite: Fix shebangs in hooks.
Date: Mon, 13 Mar 2017 15:30:01 +0100
User-agent: mu4e 0.9.18; emacs 25.2.1

ng0 <address@hidden> writes:

> On 17-03-05 16:24:14, Clément Lassieur wrote:
>> address@hidden 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.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]