Re: packaging lilypond as a docker container?

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High:
>> On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:
>> > if GUB is used, who is maintaining and/or working on it?
>> 
>> Almost exactly a year ago, there was a sizable "Please test gub" effort 
>> initiated by Knut Petersen.
>> 
>> <
>> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html
>> >
>> 
>> Clear instructions were given for exactly how to test GUB, and just that 
>> thread seems to have involved about 16 people.
>> 
>> More recently, it looks like Jonas Hahnfeld's work with Python 3 
>> migration involved quite a number of changes to GUB.
>
> Yep, and it's not been a very pleasant experience. To be precise here:
> It's not about porting GUB to Python 3, it's just that porting LilyPond
> will introduce a dependency on an updated package for the next release.
> So while David is mostly correct that contributors don't need to bother
> with GUB, that doesn't hold true once you want to bump one of its
> dependencies...
>
> Based on this experience, I've thought about how to improve the process
> of building binary releases for LilyPond. What I have been
> experimenting with is a set of portable shell scripts that build mostly
> static executables. I've a prototype ready at 
> https://github.com/hahnjo/lilypond-binaries which works for Linux and
> FreeBSD. I don't see a reason it cannot work on macOS, but I don't have
> the possibility to test...

The problem is "on macOS" since current macOSX library/toolbox licenses
all prohibit use in cross-building environments.  It looks like a given
that we will not be able to offer macOSX libraries in future as the
result of a unified release process.  Our sources build reasonably well
that macOSX integrators using some of the macOSX typical packaging
systems are able to provide reasonable replacements.

But the elephant in the room is Windows.  Han-Wen says he never wants to
touch GUB again (and he actually didn't as far as I remember) but I
don't want to touch Windows again, and GUB provides them.  The
dependency nightmare on a non-UNIX like platform was what brought GUB
into being in the first place: native builds are much more of an ongoing
problem.  Just look at the continuous effort the Git project has in
keeping a Windows version available.

>>  From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
>> something based on Guix.
>> 
>> <
>> https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html
>> >
>> 
>> That idea was mentioned a few times since, but I can't recall if 
>> GUB-replacement discussions have moved beyond that or not.
>
> As far as I understand, Guix is a package manager in the first place.
> In the thread Jan proposes to use it for cross-compilation, which I
> think is the primary reason for the complexity in GUB. So why go that
> route once more?
> Instead I designed the mentioned scripts such that they produce native
> executables. That's also how TeXlive builds their packages, for
> example, and it works quite well if you compile on the oldest OS that
> you intend to support (CentOS 7, FreeBSD 11).
>
> I haven't decided yet how to compile for Windows. Maybe that's still a
> valid use case for cross-compilation (but only with a very limited
> scope).

Windows really is the elephant in the room.  MacOSX will cater with
native port systems like MacPorts etc and other UNIX-like systems also
have working packagers and package systems.

> If this attempt sounds interesting to the community, I would be happy
> to submit the scripts for inclusion into the LilyPond repository
> itself. That would also solve another issue with GUB: Currently it's a
> separate repository with no way to keep it in sync with changing
> dependencies for LilyPond...

Maybe we should entertain two branches of GUB matching current stable
and unstable release tracks?  Or otherwise deal with a difference in
dependencies for stable/unstable?

-- 
David Kastrup