GNU bug report logs -
#25966
Fix bug 25957 and updates gitolite
Previous Next
Reported by: ng0 <contact.ng0 <at> cryptolab.net>
Date: Sat, 4 Mar 2017 12:59:02 UTC
Severity: normal
Done: Leo Famulari <leo <at> famulari.name>
Bug is archived. No further changes may be made.
Full log
Message #40 received at 25966 <at> debbugs.gnu.org (full text, mbox):
Marius Bakke transcribed 3.8K bytes:
> 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 you clarify what you mean? Convince it… how? Do you have an idea how
to achieve this, or some further thoughts on the matter?
> 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".
This bug report was last modified 8 years and 70 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.