bug#25957: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Thompson, David]

Hi all,

Reviving this old thread.

On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner <efraim@flashner.co.il> wrote:
> >
> > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve'
> > into a '/gnu/store/...' (untested), so seems actionable to me.
> > Alternatively, as Efraim wrote, let it search the $PATH (that might be
> > useful if adding svnserve would increase the closure too much and it is
> > an optional dependency in practice?).
>
> I spent some time looking at gitolite and the service. As I understand
> it, with the exception of svnserve, it searches $PATH for a number of
> different binaries, including git-annex. I believe that this would only
> work if git-annex (and potentially other packages) are installed
> globally.
>
> In addition, git (not git-minimal) and openssh are propagated inputs AND
> wrapped. I haven't tested to see if wrapping only is enough.
>
> I think the best choice is to:
> A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH,
> like it does with the other helpers.

I see that you have done this.  Thanks!  We could also replace the
reference to /usr/sbin/redis-server in src/lib/Gitolite/Cache.pm.
That's the only other /usr reference I can find (that isn't in a
comment) in the output.  I have the patch ready if that sounds good to
you.

> B: Adjust the service so that it automatically creates a variant (or
> just a wrapped version) of the package which is wrapped with a list of
> additional packages so that they can be in gitolite's path. If I were
> deploying this to an arm device I wouldn't want it wrapped with
> git-annex since it doesn't build, but would definitely want it for an
> x86_64 machine.

The service configuration record could accept a list of addons like
'(git-annex cache svnserve), with a default of no addons '(), and
create a package that extends the gitolite package with the
appropriate propagated inputs.  Does that sound like what you had in
mind?  A more robust solution could modify the build to hardcode the
store paths needed for the add-ons but given that we already propagate
git and openssh I don't think it's necessary right now.

> I suppose we should try to find someone who is using the gitolite
> service and see if they can be our test subject for wrapping the package
> with optional addons.

I use the gitolite service and can be the test subject.  I don't
currently use any add-ons, but the redis one sounds easy enough to try
and hey maybe it's a good excuse to finally learn how to use
git-annex.

As a longer term thing, it would be cool to revisit propagating git
and openssh in this package.  I punted on it back in 2015 for the
reason stated in the source comments but maybe there's a reasonable
and reliable way to directly embed the store paths now.

- Dave