base-chroot: unified for glibc and musl libc

[pullmoll]

I believe that this cannot be merged in the usual way because it is a bootstrap package and our builders depend on base-chroot. Thus it needs to be built manually for native before the cross base-chroot packages can be built by the builders.
It is meant to allow for bootstrapping *-musl architectures like x86_64-musl or ppc64-musl.
It also removes archs=noarch to create per-arch meta packages and avoid problems when forcefully rebuilding. Note that base-chroot-musl already was a per-arch meta package.

[pullmoll]

It does not yet work right. I think I need to keep the order of depends rather than what xtrimdeps made of it.

[pullmoll]

Bootstrapping on x86_64-musl doesn't find the already built packages. It fails to find the just built zlib-devel before trying to build binutils. Restarting with ./xbps-src zap;./xbps-src bootstrap builds the same packages again.

I think there is some hard coded x86_64{,-repodata} below ./common where there should be $XBPS_ARCH or perhaps $XBPS_TARGET_ARCH.

Edit: Yep, here's the debug output. Somewhere the native architecture is not set or lost:

[DEBUG] XBPS: 0.53 API: 20180730 GIT: UNSET
[DEBUG] Processing configuration directory: /dev/null
[DEBUG] Processing system configuration directory: /home/void/src/void-packages/masterdir/usr/share/xbps.d
[DEBUG] rootdir=/home/void/src/void-packages/masterdir
[DEBUG] metadir=/home/void/src/void-packages/masterdir//var/db/xbps
[DEBUG] cachedir=/home/void/src/void-packages/hostdir/repocache
[DEBUG] confdir=/dev/null
[DEBUG] sysconfdir=/home/void/src/void-packages/masterdir/usr/share/xbps.d
[DEBUG] syslog=true
[DEBUG] bestmatching=false
[DEBUG] Architecture: x86_64
[DEBUG] Target Architecture: (null)
[DEBUG] Repository[0]=/home/void/src/void-packages/hostdir/binpkgs
[DEBUG] [pkgdb] initialized ok.
[DEBUG] [repo] `/home/void/src/void-packages/hostdir/binpkgs/x86_64-repodata' open repodata No such file or directory
[DEBUG] [repo] `/home/void/src/void-packages/hostdir/binpkgs/x86_64-repodata' open repodata No such file or directory
Unable to locate 'zlib-devel-1.2.11_3' in repository pool.
[DEBUG] [pkgdb] released ok.

Running XBPS_ARCH=x86_64-musl ./xbps-src bootstrap seems to work around that.

[pullmoll]

It works for me if I specify XBPS_ARCH=x86_64-musl for a bootstrap; tested in a VM a couple of days ago. Of course it would be even nicer if XBPS_ARCH was set correctly already by xbps-src or common/whatever.

[pullmoll]

How? I don't see where XBPS_ARCH becomes x86_64 in an environment which is actually x86_64-musl.
There is no ${...%-musl} somewhere in common/* as far as I see.

[pullmoll]

There is a line export XBPS_ARCH=${XBPS_ARCH:-$(cat $XBPS_MASTERDIR/.xbps_chroot_init)} which reads the arch from .xbps_chroot_init. Perhaps the problem is there just because of the unsolved #10299 which I think should be fixed by the people who broke it in the first place :)

[pullmoll]

It is required because you need an ada compiler to build ada. Since a package cannot depend on itself, gcc-ada had to become installed as part of base-chroot. Otherwise you would always need to build gcc using a 3rd-party gcc-ada.

[pullmoll]

Ada is used e.g. by several of our users and is e.g. used to build some of the coreboot files.
Personally I don't need it while there have been requests to add it since 2015.

[pullmoll]

But if you don't have gnat (built in the chroot as part of gcc) you cannot compile gcc-ada ;-P
The entire issue took me literally weeks last year to solve. If you find a better solution, it's certainly appreciated.

[pullmoll]

Then gcc-ada would have to be a package independent of gcc and you would always need a 3rd-party gcc, not the void gcc, to build gcc-ada. If you need another argument: LFS builds gcc-ada as part of gcc (no, BLFS has it separated and uses the adacore.com toolchain).
AFAICT many Linux distributions also build ada with their system's gcc.
Last not least building cross-ada is required to be able to have gcc-ada for all supported target architectures. You won't find gnat for all supported architectures elsewhere.

[pullmoll]

phew it really took me weeks to solve this somehow. I don't think the + 1/5th of build time for gcc actually matters that much nowadays compared to the trouble of getting it built with 3rd-party toolchains.

[pullmoll]

@xtraeme a x86_64 bootstrap is running here now. I can also test a native ppc64 bootstrap but that will take at least 5 hours to finish :)

[pullmoll]

superseeded by #11282