Re: [lmi] [lmi-commits] master 0d823ab 11/12: Merge 'lmi_setup_41.sh' into 'lmi_setup_40.sh'

[Greg Chicares]

On 2020-06-13 13:20, Vadim Zeitlin wrote:
> On Sat, 13 Jun 2020 13:13:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...script names matching regex /lmi_setup_[0-9][0-9][rc]*\.sh/ ...]

>  It would seem to me that using more semantic names could be useful even
> during the (unavoidably messy) initial process, but this is up to you, of
> course.

For these files, existence precedes essence, so a descriptive name for
a file would evolve as we discover its purpose. But git tracks content,
not files, so it's less disruptive to change a comment than a filename.
Once we know the true purpose of every script, we can devise a good name
for it...probably at the same time that we merge all the scripts into
functions that reside in a single file (if my sh-fu is strong enough).

[...numeric infixes as in 'lmi_setup_41.sh'...'

>  Just for the record: in the case of GRUB, and many other *.d directories,
> they definitely are essential as the files are read in their alphanumeric
> order and the latter files override the earlier ones. I.e. the file names
> define the order. This may not be the best idea, but it's very much a
> standard one and a widely used one, at least in Debian.

I had at one time hoped to be able to use 'run-parts' here.
Then I discovered that some parts needed to vary for
  {debian,centos,redhat}
although it would also be possible to replace #10, #10c, and #10r
(for example) with a single #10 with a {,c,r} case...esac switch.

But that's just a question of what glue we use to bind all the
parts together. For now, I want to finish defining the parts,
and getting them all to work correctly together. Accordingly, my
priority is fixing these things:
  cp: preserving times for '/some/file': Operation not permitted
(use 'install' instead--commits to be pushed soon) and
  No protocol specified
for which I'm testing this expedient:
  install -m 0666 /home/greg/.Xauthority 
/srv/chroot/centos7lmi/srv/chroot/lmi_bullseye_2/home/nemo

> GC> Yes, perhaps refactoring everything into shell functions rather than
> GC> shell scripts would be better, especially as the number of scripts
> GC> increases (and this commit is probably the only one where that number
> GC> has decreased). But that change can be made mechanically once the
> GC> design has stabilized.
> 
>  Again, it just seems to me that refactoring functions inside the same file
> would be simpler than refactoring across files, which is why I proposed
> doing it like this, but if you prefer working with multiple files, this is
> not a problem, of course.

Multiple script files is an improvement:
  git show 237f11ea0
over multiple script-file stanzas written as here-documents and
embedded in one monolithic script which calls the scripts it
creates. Compared to that, file multiplicity is a "good problem"
to have. However, it's coming to look like a problem nonetheless.