Re: Please test new lilypond installers

[David Wright]

On Tue 29 Jan 2019 at 12:19:11 (+0100), Johan Vromans wrote:
> On Tue, 29 Jan 2019 10:19:33 +0100, Knut Petersen
> <address@hidden> wrote:
> 
> >     lilypond-2.21.0-1.linux-64.sh
> 
> I tried an install into /opt/lilypond. I do not have access to /opt but the
> folder /opt/lilypond is completely mine.
> 
> The help says it will install into PREFIX/lilypond, but it also tries to
> install scripts outside this directory in PREFIX/bin.

Yes, PREFIX/lilypond contains the distribution and PREFIX/bin is for
all the wrappers which can go into your PATH.

So, if /opt/lilypond is under your control, you'd normally put a
distribution into, say, PREFIX/lilypond/lilypond-2.21.0-1.linux-64
which (a) makes it trivial to support multiple versions and (b)
means you can put, say, your own local lilypond-support-programs
into /opt/lilypond without polluting the distribution.

> It refuses to install into an existing (even empty¹) directory. While this
> may be good in some cases, it would be nice if this could be overridden.
> 
> Fun fact: The script first checks if the directory exists and bails out if
> so. If not, it carefully checks if the directory exists before creating
> it :).

Creating the top-level directory is safe. Anything else risks
polluting the distribution with other files. It's trivial to
move the new lilypond-xxx tree yourself after it's been created
and, that way, you take responsibility for any merging or overwriting
that takes place as a result.

So it's not worth putting the complication² into the installer
rather than leaving it as the responsibility of the sysadmin.

> I choose to install with PREFIX=/opt/lilypond and everything went fine.
> 
>    $ /opt/lilypond/bin/lilypond --version
>    GNU LilyPond 2.21.0
> 
> Verified some scores with Frescobaldi, looks ok.
> 
> Good job!

¹ It's no big deal to install into PREFIX=…/<empty>/<new-distribution>
and then type
  mv …/<empty>/<new-distribution>/* …/<empty>/
  rmdir …/<empty>/<new-distribution>

² for example, what happens when there's a file in the distribution
whose name coincides with a directory in the target? (Or vice versa.)
If you decide under those circumstances to back out, who's responsible
for cleaning up the files already written? We now need a manifest with
MD5s so the installer can distinguish its own files from the ones that
were or were not overwritten.

Cheers,
David.