On Fri, Sep 02, 2022 at 03:58:09PM -0400, Thompson, David wrote: > On Fri, Sep 2, 2022 at 8:50 AM Thompson, David wrote: > > > > On Fri, Sep 2, 2022 at 8:44 AM Efraim Flashner wrote: > > > > > > On Fri, Sep 02, 2022 at 07:11:54AM -0400, Thompson, David wrote: > > > > On Fri, Sep 2, 2022 at 3:00 AM Efraim Flashner wrote: > > > > > > > > > > I took a look at the gitolite service finally and I hadn't realized > > > > > there wasn't a running daemon to containerize. I assumed we could do > > > > > something like: > > > > > > > > > > (start $~(make-forkexec-constructor/container > > > > > (list ...) > > > > > #:environment-variables > > > > > '("PATH=...") > > > > > #:mappings ...)) > > > > > > > > > > Given that's not the case then I'd need to look at gitolite itself to > > > > > see how it calls the other binaries it expects to be available, and if > > > > > wrapping it would be enough or if we would need to just propagate the > > > > > other packages for functionality. > > > > > > > > Gitolite simply expects tools like git to be on $PATH. It's a pretty > > > > naive system, there's nothing like a configure script that is > > > > determining the absolute file name of these tools and substituting > > > > those names into the built files. > > > > > > > > The executable is already wrapped so that coreutils, findutils, and > > > > git are on $PATH, but notably not openssh: > > > > > > > > (add-after 'install 'wrap-scripts > > > > (lambda* (#:key inputs outputs #:allow-other-keys) > > > > (let ((out (assoc-ref outputs "out")) > > > > (coreutils (assoc-ref inputs "coreutils")) > > > > (findutils (assoc-ref inputs "findutils")) > > > > (git (assoc-ref inputs "git"))) > > > > (wrap-program (string-append out "/bin/gitolite") > > > > `("PATH" ":" prefix > > > > ,(map (lambda (dir) > > > > (string-append dir "/bin")) > > > > (list out coreutils findutils git))))))) > > > > > > > > However, git and openssh are still propagated inputs. I'm going to > > > > move the propagated inputs to regular inputs, potentially add openssh > > > > to the wrapper once I remind myself what gitolite does with those > > > > tools, and test it all out on my server using the gitolite service. > > > > If that all works, we have a good starting point for adding extension > > > > support in the service. > > > > > > I like it. Let us know how it goes. > > > > The problem is that gitolite generates git hooks for the repositories > > that it manages, and those hooks invoke git, so the only way those > > scripts will be able to work (without input propagation) is to find a > > way to inject the proper PATH or find a way to replace references to > > things like 'git diff' with '/gnu/store/.../git diff'. I'm going to > > keep exploring and report back when I have something to show. > > After several rounds of experimentation and breaking my git server a > few times, here's what I've found: > > * Changing git and openssh to be regular inputs and wrapping both > gitolite and gitolite-shell with a $PATH that contains git works and > it's very little extra code. > > * Trying to replace every invocation of a git command took a lot of > grepping and crafting of regexps to use for substitute* and I never > got to a point where the result wasn't buggy. In particular, > gitolite-shell never worked properly so I couldn't push to my repos. > > So, I think the simple wrapper approach is the way to go. Patch > attached. I tested on my git server by making changes to my gitolite > configuration and pushing those changes to the special gitolite-admin > repo. This causes gitolite to refresh internal configuration using a > git hook, so I know that hooks can find the executables they need. > That plus the 'gitolite setup' invocation made by the service > activation script covers a fair amount of surface area, so I feel > comfortable committing it. What do you think? > > Once this part is done, I'll turn my attention to the optional extensions. Overall it looks good to me. I was going to ask about inetutils and openssh since they're not wrapping the binaries but I see their paths are substituted in the 'patch-source phase. LGTM! > From 413f2d28aa8bea2274b74c2b574fb9f8bf9c16ba Mon Sep 17 00:00:00 2001 > From: David Thompson > Date: Fri, 2 Sep 2022 14:33:01 -0400 > Subject: [PATCH] gnu: gitolite: Wrap programs instead of using propagated > inputs. > > * gnu/packages/version-control.scm (gitolite)[arguments]: Add git to wrapped > $PATH and additionally wrap gitolite-shell. > [inputs]: Add git and openssh. > [propagated-inputs]: Remove it. > --- > gnu/packages/version-control.scm | 18 ++++++++---------- > 1 file changed, 8 insertions(+), 10 deletions(-) > > diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm > index 15a9278fe8..1c775932c0 100644 > --- a/gnu/packages/version-control.scm > +++ b/gnu/packages/version-control.scm > @@ -1573,17 +1573,15 @@ (define-public gitolite > (coreutils (assoc-ref inputs "coreutils")) > (findutils (assoc-ref inputs "findutils")) > (git (assoc-ref inputs "git"))) > - (wrap-program (string-append out "/bin/gitolite") > - `("PATH" ":" prefix > - ,(map (lambda (dir) > - (string-append dir "/bin")) > - (list out coreutils findutils git)))))))))) > + (for-each (lambda (file-name) > + (wrap-program (string-append out file-name) > + `("PATH" ":" prefix > + ,(map (lambda (dir) > + (string-append dir "/bin")) > + (list out coreutils findutils git))))) > + '("/bin/gitolite" "/bin/gitolite-shell")))))))) > (inputs > - (list bash-minimal perl coreutils findutils inetutils)) > - ;; git and openssh are propagated because trying to patch the source via > - ;; regexp matching is too brittle and prone to false positives. > - (propagated-inputs > - (list git openssh)) > + (list bash-minimal git perl coreutils findutils inetutils openssh)) > (home-page "https://gitolite.com") > (synopsis "Git access control layer") > (description > -- > 2.37.2 > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted