Hi Andrius, On Tue, 09 Jul 2024 at 23:15, Andrius Štikonas <andr...@stikonas.eu> wrote:
>> Do you mean remove guile-bootstrap from the picture? The root of this >> graph: > > I think what janneke means (correct me if I'm wrong) is that before now gash > and gash utils could only run on guile but not on mes. So that arrow that was > pointing from gash to guile-bootstrap will point to mes. It would mean to have mes-bootstrap (instead of guile-bootstrap) that would be indirectly used by mes-boot. Right? >> https://www.gnu.org/software/mes/manual/images/gcc-mesboot-graph.png >> >> ? What’s the plan? Replace the requirements of stage0-posix provided >> by Gash and Gash-Utils by increasing bootstrap-seeds? > > bootstrap seeds bubble in that graph refers to [1], so it wouldn't be > changing > as we don't add anything else there. > > stage0-posix requirements are related to package manager and/or limitations > of > source distribution method. If stage0-posix exists in unpacked form, it can > run the whole bootstrap chain itself using either kaem-optional-seed [2] in > userspace/POSIX bootstrap (e.g. just kernel and initramfs with > bootstrap-seeds > and source) or builder-hex0 [3] (plus sources) in MBR/BIOS bootstrap (where > we > bootstrap linux kernel too). And then no guile-bootstrap is needed at all. > Both of these problems are already solved on x86 (though now new x86 machines > generally come without BIOS and bootstrapping on UEFI is only partially done). Thanks for explaining. [...] > What would be interesting from bootstrapping perspective is to make those > additional seeds (guile-bootstrap in particular) fully bootstrappable/ > reproducible not just from inside Guix but also without Guix, so that we > don't > have chicken and egg problem of how to build guile-bootstrap binary when we > don't yet have Guix. Hum, I am missing something, I guess. Well, from my poor understanding, one way is what you explained just above or something as “Extreme“ Bootstrapping as discussed in [4], and the other way is to root the graph in some binary driver (as guile-bootstrap). For sure, the binary guile-bootstrap could be replaced by another lighter, smaller and surely more reproducible other binary as mes-bootstrap but that would not tackle the chicken-or-the-egg problem, IMHO. However, it could be nice to reduce again the binary footprint. Well, from my weak understanding, maybe one direction (but huge work) would to implement all the features required by the whole graph and provided by gash-boot and gash-utils-boot directly in auditable binary. Yeah, it’s a piece of work and I do not volunteer. ;-) Cheers, simon 4: https://guix.gnu.org/en/blog/2019/reproducible-builds-summit-5th-edition/
