bootstrap-prefix.sh always installs the latest unstable glibc. As it's sometimes needed to install alternative versions and it's not possible to downgrade glibc after bootstrap, the GLIBC package atom was made customizable. --- a/bootstrap-prefix.sh +++ b/bootstrap-prefix.sh @@ -1846,12 +1846,16 @@ bootstrap_stage3() { dirname $(gcc -print-libgcc-file-name) > "${ROOT}"/etc/ld.so.conf.d/stage2.conf fi + if [ -z "$GLIBC"]; then + GLIBC=sys-libs/glibc + fi + pkgs=( sys-apps/baselayout sys-apps/gentoo-functions app-portage/elt-patches sys-kernel/linux-headers - sys-libs/glibc + $GLIBC ) BOOTSTRAP_RAP=yes \ Reproducible: Always
I'm fine with something like this, but I think the name needs to be different. @heroxbd: what do you think? Alternative route would be via a package.mask entry. Perhaps we can generalise maskings/etc that way somehow.
alternative thought, with the current patch it seems possible to use musl or uclibc as well, I wonder how that pans out with the rest of the script.
Now that you mention package.mask, this patch could work for stage2 but not for stage3 where a simple emerge @system is issued. If I'm not mistaken, a package.mask entry should also be needed to prevent emerge @system command to prevent glibc from being upgraded.
Well, my thoughts were that we'd add a hook to set package.mask entries during stage2, stage3 and the final emerge -e system. In other words, after unpacking a tree snapshot, and after the sync of the tree. I could think of something like an environment variable that points to a file that is copied, or if it doesn't point to a file, then its contents is echoed to package.mask.
I'm not sure about the level of support you provide to your users but allowing users to plug arbitrary package.mask files could prove to be a support nightmare. What about this approach? This is heeded by all stages. LIBC_MASK=>sys-libs/glibc-2.28 ./bootstrap-prefix $PWD --- a/util/bootstrap-prefix.sh +++ b/util/bootstrap-prefix.sh @@ -503,6 +503,11 @@ bootstrap_setup() { # trade-off is just not to use cxx. dev-libs/gmp -cxx EOF + + if [ -n "$LIBC_MASK" ]; then + echo "$LIBC_MASK" >> "${ROOT}"/etc/portage/package.mask + fi + } do_tree() {
I think package.mask makes more sense. Because it prevents you from installing undesired newer version of glibc after bootstrap as well. > allowing users to plug arbitrary package.mask files could prove to be a support nightmare. Concluding it as a "nightmare" is too harsh, if you understand what skills a typical Gentoo user has. The users who even care the version of glibc will feel comfortable tweaking packages.mask, or comment out the code in the ebuild that prevents you from downgrading. Thank you Burak. But I don't like introducing more switches to the script. As you are showing us, you could easily modify the script to fit your needs. Looking forward to your future bug reports and patches. That said, @Fabian may have different opinion on this.
I think I'll add a secret hook (there are more of those present already). I see use for this while trying to get bootstraps to succeed; sometimes the latest snapshot isn't even good enough.
There should be *more* parameters not less. I'd add stuff like FEATURES, CFLAGS, MAKEOPTS etc in the same way I proposed to add package.mask (though more and more I think about it, I tend to agree with Fabian about PACKAGE_MASK being a file name to be copied inside the prefix rather than its contents). eg: FEATURES="noinfo noman nostrip installsources" CFLAGS="-Og -ggdb" ./bootstrap-prefix.sh /opt/gentoo noninteractive Making this consistent is a bit of a challenge though. For example FEATURES here needs to put the following in the make.conf: FEATURES="${FEATURES} noinfo noman nostrip installsources" # appends stuff whereas CFLAGS needs to generate the following: # overrides stuff CFLAGS="-Og -ggdb" CXXFLAGS="${CFLAGS}" Why use MAKEOPTS and not USE_CPU_CORES? Because it is an antipattern (micromanagement) because make accepts a load limit parameter as well. In our buildfarm, we like to run low-priority jobs with: MAKEOPTS="-j$(( `nproc` / 2 )) -l$(( `nproc` * 3 / 2))" so that it waits for the load avg to fall under a certain threshold to start new jobs. ps: Why is there no mailing list for gentoo-prefix? did I miss it?
In my opinion, only the final emerge -e system stage should include CFLAGS, FEATURES etc. Before that, it's not safe (and gets messy) to fiddle with things like that. I think it makes sense to allow customising the final full rebuild of the Prefix. This is an advanced usage feature for sure.
> ps: Why is there no mailing list for gentoo-prefix? did I miss it? Historical reasons. We use gentoo-alt ML.
After stage3, we should allow a wide variety of customisations, at the responsibility of the user. This should be fairly simple, yet the means are kind of unclear. We could easily set CFLAGS, FEATURES, etc, but perhaps the better choice is to allow calling a script that can modify the EPREFIX right before the final emerge -e world. That way, even packages can be added (via packages file). Trickier, is the glibc (or other libc) controlling. This needs special handling, so as to ensure it is the desirable version from stage2 onward.
