[tlbuild] Support for musl

[Henri]

On Tue, 2018-01-23 at 12:53 +0900, Norbert Preining wrote:
> On Tue, 23 Jan 2018, Henri wrote:
> > 
> > Well, TeX live already pulls in specific versions of the libraries instead of always using
> > upstream,
> Huu? No, we try to use the latest released versions as far as possible.
> Of course, that is released at the time of the binary builds, so the
> for 2017 around March 2017 it was.

I realised that this was only an issue in TeX live 2017.  Using the TeX live 2018 development
sources from your mirror at https://github.com/TeX-Live/texlive-source it compiles fine on the
latest stable release of Alpine Linux (3.7).  Enclosed in this email you can find an updated version
of .travis.yml which tests the build on Alpine 3.7 using the Docker capabilities of Travis CI.

One thing remains though.  Sometimes the build crashes with

/texlive/build-aux/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
         You should only need it if you modified a '.texi' file, or
         any other file indirectly affecting the aspect of the manual.
         You might want to install the Texinfo package:
         <http://www.gnu.org/software/texinfo/>
         The spurious makeinfo call might also be the consequence of
         using a buggy 'make' (AIX, DU, IRIX), in which case you might
         want to install GNU make:
         <http://www.gnu.org/software/make/>

but I am using GNU make.  Also this happens totally non-deterministically.

> 
> > 
> > so I guess it wouldn't be too bad.  And that is what Debian is doing as well, right?  Using
> > upstream
> > and applying Debian-specific patches to make stuff compile.
> We are not Debian ;-)
> Well yes, we do apply patches but try to keep them to a minimum and feed
> them back upstream. Mostly fixes for arcane architectures etc.
> 
> I guess it all boils down to
> - size of the patches
> - maintainability
> - will of the patch author to maintain the stuff and update it for new
>   releases
> 
> > 
> > Indeed.  I'm am not requesting that you rewrite all infrastructure right now!  But it is
> > certainly
> > something to keep in mind for the future, especially if more Linux distros are picking up musl.
> >  It
> > is already in Debian (and others) so it's just a matter of time until they ship musl-based
> > releases.
> I will keep it in mind, and in some spare time look into supporting
> extended architecture names. Concerning Debian - having musl in there is
> not even the slightest indication the Debian wants/will switch to it as
> *default* C-lib. I still remember the a.out -> ELF switch which was a
> similar pain, and former libc switches (temporary elibsomething), but
> they were mostly compatible. It was a huge pain.
> 
> > 
> > binaries).  Since musl is still kind of esoteric, I would guess that only non-idiot people use
> > it
> > and are aware of the consequences, so they should be able to use the custom-bin options without
> > a
> > struggle.
> Here I agree, normal users will never start playing around with libc
> changes, this is also my guess.
> 
> Norbert
> 
> --
> PREINING Norbert                               http://www.preining.info
> Accelia Inc.     +    JAIST     +    TeX Live     +    Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .travis.yml
Type: application/x-yaml
Size: 931 bytes
Desc: not available
URL: <http://tug.org/pipermail/tlbuild/attachments/20180124/d71d71f6/attachment.bin>