Re: [lmi] Sharing git repositories

[Greg Chicares]

On 2020-03-10 01:32, Vadim Zeitlin wrote:
> On Mon, 9 Mar 2020 23:21:51 +0000 Greg Chicares <address@hidden> wrote:
> 
[..."case B1" is the wx* repositories on our corporate server...]
> 
> GC> Even case B1 is "interesting", as these aren't bare repositories:
> GC> 
> GC> /srv/cache_for_lmi/vcs/wxWidgets[0]$git rev-parse --is-bare-repository
> GC> false
> GC> /srv/cache_for_lmi/vcs/wxpdfdoc[0]$git rev-parse --is-bare-repository
> GC> false
> GC> 
> GC> Those are the result of deleting any cached copies and then running
> GC> the normal scripts, e.g., in 'install_wx.sh':
> GC> 
> GC>   git clone "$coefficiency" --recurse-submodules "$remote_host_url" 
> $repo_name

It's even more interesting on my own debian machine [0], which has
two copies, one bare and one non-bare. Anyway, something's gone awry
here, so let's step back and try to decide what the intention was
(or what it should be). The original idea was like this:

 - directory /srv/cache_for_lmi/ should hold cached copies of files
   that rarely change and are inconvenient to download (e.g., because
   downloading takes too long, or some source site like sf.net is down,
   or (on the corporate server) a site is blocked), and it was natural
   enough to add a vcs/ subdirectory there for git repositories that
   we rarely update

 - directory /srv/chroot/ should hold one or more chroots where the
   actual lmi work is done

 - scripts that create a new chroot would copy the cache, e.g.:
     cp -a /srv/cache_for_lmi/* /srv/chroot/new_chroot/cache_for_lmi/

Thus, this directory:
  /srv/cache_for_lmi/vcs/
would hold only bare repositories, and this one:
  /srv/chroot/new_chroot/cache_for_lmi/vcs/
would hold copies of those same bare repositories.

Then (in commit b80b1ae2ed of 20191004) I decided to...

    Experiment with bind mounts
    
    It takes a little over forty minutes to run 'install_centos.sh'.
    Perhaps it would be faster if the host system's /var/cache could
    be used for apt and yum inside the (nested) chroots.

and, even though the point was to optimize apt and yum, I incidentally
did this:

+# This seems to work perfectly:
+mkdir /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/cache_for_lmi
+mount --bind /srv/cache_for_lmi 
/srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/cache_for_lmi || echo "Oops"

Then I reran 'install_wx.sh', which did this:
    cd /cache_for_lmi/vcs/wxWidgets
    git clone --recurse-submodules "$remote_host_url" wxWidgets
thereby downloading a non-bare copy to what seemed to be a directory
local to the chroot, but because of the bind mount was actually a
directory on the host system.

Wouldn't it make more sense to return to the original design intention,
so that /var/cache_for_lmi/ would hold only bare repositories with
'core.sharedRepository' set for all? Thus, we'd:
 - set up bare 'core.sharedRepository' repos on /srv/cache_for_lmi/ and
 - bind-mount them as read-only inside each chroot
For the wx repository, we'd only need to override this line:
  
remote_host_url=${remote_host_url:-"https://github.com/wxWidgets/wxWidgets.git"}
e.g. with
  remote_host_url="file:///cache_for_lmi/vcs/wxWidgets.git"
provided that such a file exists.

Would it be even better to use the local cache as a "reference repository"?
The documentation for '--reference' here:
  https://git-scm.com/docs/git-clone
refers to the "NOTE" for '--shared', which says:
|  this is a possibly dangerous operation;
|  do not use it unless you understand what it does
which leads me to think I might be better off not venturing into this
unknown territory. We update wx and wxpdfdoc so infrequently that it
might be better for us just to remember to update them only in the
host system's /var/cache_for_lmi/ rather than in any chroot.

But wait...it looks like '--shared' and 'core.sharedRepository' are
one and the same, so we're venturing into that territory anyway, and
maybe it's no more difficult to add '--reference' at the same time.

> GC> Should that be a bare repository instead?
> 
>  Well, "should" is a difficult question. What I can say is that right now,
> it can't, because we use files from its working copy (first config.status,
> then configure and then all the sources when building).
> 
>  However it does bother me that this repository, used for building lmi,
> lives in a central location. This is not really compatible with the idea of
> building lmi from different user accounts, and even though you found a
> workaround for this with making the files group-accessible, it would still
> be cleaner, IMHO, to just use different repositories for the different
> users.

I suppose that could be handled by setting a different $prefix.
(I don't think I've ever tried that with lmi, so I don't know whether
it would work today; but if it doesn't, that's a defect that should
be addressed, because we have a compelling use case for it now.)

Note that 'install_wx.sh' sets a build directory that looks like it
could vary by user just by overriding $prefix:
  build_dir="$exec_prefix/wx-ad_hoc/lmi-$LMI_COMPILER-$gcc_version"
whereas above I'm talking about a "reference repository" that would
appropriately live in one central location.

>  In fact, if I were doing this afresh, I would have a pristine copy of the
> upstream repository in some central location on the server and it would
> indeed be bare. Then I would clone this repository to a per-used lmi build
> directory and proceed from there.

Ah. Yes, I think that's what I'm trying to say.

>  But this wouldn't be really compatible with the idea of having a single
> script doing it all, as you'd need to set up the per-machine clone first
> and then run the rest of install_wx.sh for each user.

Well...we'd have
 - a single script to configure the "host" system
 - a single script to create the debian-testing chroot
 - a single script to be run once per user
which would look something like this non-working, uncommitted change:

diff --git a/install_redhat.sh b/install_redhat.sh
 cp -a lmi_setup_*.sh /tmp/schroot_env /srv/chroot/${CHRTNAME}/tmp
 schroot --chroot=${CHRTNAME} --user=root             --directory=/tmp 
./lmi_setup_20.sh
 schroot --chroot=${CHRTNAME} --user=root             --directory=/tmp 
./lmi_setup_21.sh
+# also need parts of script _41 for identity mounts
+# how about script _40 to create a wine "prefix"?
+for z in $(getent group "$NORMAL_GROUP" | cut -d: -f4 | sed -e's/,/ /g'); do
+  printf "Setting up chroot user %s\n" "$z"
+  schroot --chroot=${CHRTNAME} --user=root           --directory=/tmp 
./lmi_setup_22.sh
+done
 sudo                         --user="${NORMAL_USER}"                  
./lmi_setup_30.sh

Then in an appropriate sub-script we could do something like
  prefix="${NORMAL_USER}-prefix"
and 'install_redhat.sh' would regenerate everyone's universe.

---------

[0] "It's even more interesting on my own debian machine"

...which has both a bare and a non-bare repository:

/srv/cache_for_lmi/vcs/wxWidgets[0]$git rev-parse --is-bare-repository 
false
/srv/cache_for_lmi/vcs/wxWidgets.git[0]$git rev-parse --is-bare-repository      
  
true

The bare one doesn't seem to have been updated with git-fetch
in the last couple of years:

/srv/cache_for_lmi/vcs[0]$ls -ld wxW*   
drwxr-xr-x 19 greg greg 4096 Oct  4 15:35 wxWidgets
drwxr-xr-x  7 greg greg 4096 Apr 15  2018 wxWidgets.git

...whereas the non-bare one seems to have been changed:

/srv/cache_for_lmi/vcs/wxWidgets[0]$git status                            
HEAD detached at f741031e69
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)

        modified:   src/expat (modified content)

no changes added to commit (use "git add" and/or "git commit -a")

...but it seems not to have been changed recently:

/srv/cache_for_lmi/vcs/wxWidgets[0]$ls -l src/expat 
total 24
-rw-r--r--  1 greg greg 4944 Apr 17  2018 README.md
-rw-r--r--  1 greg greg 6152 Apr 17  2018 appveyor.yml
drwxr-xr-x 11 greg greg 4096 Apr 17  2018 expat
drwxr-xr-x  3 greg greg 4096 Apr 17  2018 testdata
/srv/cache_for_lmi/vcs/wxWidgets[0]$ls -ld src/expat
drwxr-xr-x 4 greg greg 4096 Apr 17  2018 src/expat

...yet 'git-diff' shows no difference. Aha: it's a submodule, so

/srv/cache_for_lmi/vcs/wxWidgets/src/expat[0]$git status
HEAD detached at 6b2e0e6
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        typechange: README.md

...and I guess this diff:

diff --git a/README.md b/README.md
deleted file mode 120000
index 11ddc58..0000000
--- a/README.md
+++ /dev/null
@@ -1 +0,0 @@
-expat/README.md
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..984e927
--- /dev/null
+++ b/README.md
[...]

...just means that the README file was a symlink that was
replaced by a copy.