ng0 <contact.ng0@cryptolab.net> writes:
Toggle quote (64 lines)
> Marius Bakke transcribed 3.8K bytes:
>> Clément Lassieur <clement@lassieur.org> writes:
>>
>> > ng0 <contact.ng0@cryptolab.net> writes:
>> >
>> >> On 17-03-05 16:24:14, Clément Lassieur wrote:
>> >>> contact.ng0@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?
It was just a passing thought, but I don't think it's a good solution
since we don't want users to rely on potentially outdated versions of
perl. So a 'special-file-service' for '/usr/bin/perl' is indeed better.
Or perhaps use "env" from coreutils to execute whatever perl is in PATH.
