ng0 writes: > Marius Bakke transcribed 3.8K bytes: >> Clément Lassieur writes: >> >> > ng0 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.