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

Previous Next

Full log

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

From: Marius Bakke <mbakke <at> fastmail.com>
To: Clément Lassieur <clement <at> lassieur.org>, 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 18:00:51 +0100

[Message part 1 (text/plain, inline)]

Clément Lassieur <clement <at> lassieur.org> writes:

> 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.)

So the problem is that created repositories has a perl reference that is
not visible to the garbage collector. Would it be possible to convince
Gitolite to create GC roots for each repo? That's about the only thing I
can think of that will work on both GuixSD and foreign distros.

Using the "special-files-service-type" to create /usr/bin/perl on GuixSD
seems "hacky"; users might want to have a different perl in "/usr/bin".

[signature.asc (application/pgp-signature, inline)]

Previous Next

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