Re: [lmi] Creating an lmi schroot from scratch

[Greg Chicares]

On 2020-07-20 19:33, Vadim Zeitlin wrote:
[...]
>  I've finally tried to do this, but quickly realized that adapting
> lmi_setup*.sh scripts to my use case was hopeless, as they're solving a
> rather different task from what I need to do. Basically, these scripts
> initialize plenty of things from scratch (including many that I don't need
> or want at all, e.g. I really, really would hate if the automatic script
> touched to my precious hand-crafted Git configuration), while I just want
> to be able to install the dependencies and build lmi when I already have
> its checkout. I.e. I start from a working system and an existing Git
> repository rather than some primordial void, unlike these scripts.

Starting from primordial chaos is the use case that motivates these scripts.

That's important on a corporate server that's administered by persons
unknown to us, in ways that might make little sense to us. For example,
when they decided that we had to migrate to a particular filesystem that
has no tools for migrating from ext{2,3,4}, it was quite convenient to
remove everything and start again from nothing. That takes a large fraction
of an hour, but it runs unattended, so an hour doesn't matter.

AIUI, you were going to try running these scripts in a redhat or centos
(version 7) VM only. Then you'd have exactly the same nested debian chroot
in that system as the one we use. That's not really necessary--you've done
without it for decades--but that's what these scripts do, if you want that.

>  The two approaches are simply not reconcilable, and I can't even use
> install_msw.sh because of this, as it assumes that it needs to run Git
> checkout too ("inhibit_git_clone" doesn't help because, first of all, my
> checkout is never in /opt/lmi/src/lmi and I don't want to eviscerate
> anything anyhow).

That script fits a different primordial-void use case; it creates only
a galaxy, if you will, rather than an entire universe. Corporate reality
is that every couple of years they replace your hardware, supposedly
copying all your files and permissions, but they never get it right and
it's best to eviscerate it and start over.

>  One tiny thing I've noticed while writing and testing them was that
> apt-get invocation in lmi_setup_20.sh didn't install "patch". I guess it
> must be installed by default on RHEL, as I don't really understand how
> could it work otherwise, knowing that patch is used in lmi_setup_21.sh.
> It's probably not really necessary to do anything here, but I'd still add
> "patch" to the list of installed packages just to be sure it's installed.

Actually, by that time, we're in a (possibly nested) debian chroot,
so perhaps it's installed by
  debootstrap --variant=minbase
? No, apparently not--I had thought it was part of gnu diffutils,
which is part of "minbase", but 'patch' is not in the file list for
diffutils. It's installed later, as a consequence of this command:

apt-get --assume-yes install wget g++-mingw-w64 automake libtool make \
 pkg-config git cvs zsh bzip2 unzip sudo wine default-jre jing trang \
 g++-multilib libxml2-utils libxslt1-dev vim-gtk vim-doc shellcheck \
 bc libarchive-tools xsltproc rsync curl bsdmainutils \

which reports:

  The following additional packages will be installed:
  ...
  Selecting previously unselected package patch.

and
  apt-cache rdepends --installed patch
suggests that it's required by 'git', but the 'git' package seems
only to recommend it.

I can demonstrate that 'patch' is installed, but I can't prove that it
must be, so I'll just add it to the 'apt-get' command above.

> GC> And if you devise a way to use these scripts without root privileges,
> 
>  This isn't possible as long as we use the directories outside of the
> current one and home directory, i.e. /opt/lmi, /etc/opt/lmi, /var/opt/lmi
> and /srv/cache_for_lmi. I think it would be worth changing this as using
> directories under / is a MSW-ism which is being phased out even on this
> platform and is basically unheard of under Unix. The only one which is
> somewhat non-trivial is /etc/opt/lmi, which should be made configurable,
> instead of hard-coding it in both makefiles and sources.

AIUI, /{etc,var,srv,opt} are unixisms, unheard of with msw, but explicitly
allowed by the FHS. And only root can create subdirectories in them, because:

$ls -ld /etc /opt /srv /var
drwxr-xr-x 129 root root 12288 Jun 24 12:17 /etc
drwxr-xr-x   3 root root  4096 Sep  4  2019 /opt
drwxr-xr-x   4 root root  4096 Sep 12  2019 /srv
drwxr-xr-x  11 root root  4096 Sep  3  2019 /var

Where in a standard unix hierarchy could you install lmi without using
'sudo mkdir' (or equivalent) at all? Only in your home directory?

>  To try making this post at least somewhat constructive, I think it would
> be nice to factor the post-build part of install_msw.sh out of it, e.g.
> maybe have a separate post_install.sh or a "configure_settings" target in
> the main makefile, that would create expiry, validated.md5 and passkey files
> as well as configurable_settings.xml itself. And if we could make locations
> of these files configurable/overridable via environment/make variables, it
> would be even more convenient.
> 
>  Would it be useful to try to propose patches doing this?

What's your endgame? I hesitate to make small, isolated improvements
that won't get us to where you want to be (e.g., splitting install_msw.sh
into two scripts). IIRC, your chief dissatisfaction with lmi's makefiles
is that $prefix is assumed to be a hardcoded /opt (not everywhere, but
in multiple places), whereas it ought to be configurable; is that the
biggest issue, which we ought to address first? A year or two ago, I took
some steps in that direction, as this command shows:
  git log --since=2019-01-01 -G'exec_prefix' GNUmakefile
and it would be good to finish that work. My own chief complaint is that
these makefiles don't build lmi's GUI for linux-pc-gnu (IIRC, although
the unit tests do build) and that they don't support any post-1990s
compiler other than gcc.