Re: packaging lilypond as a docker container?

[Jonas Hahnfeld]

Am Dienstag, den 21.01.2020, 11:28 +0100 schrieb 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.

So if I provided a working script to build a zip file for Windows,
would you be ok with switching away from GUB?

In that case I just noticed that I missed one character in my message:
> I'm not going to tackle this until we've switched to Python *3*:
> Then we can just use the embeddable zip file provided by the Python
> project without bothering with cross-compilation for this beast.
> Everything else (Guile etc.) worked without problems in my early tests.

Jonas

signature.asc
Description: This is a digitally signed message part