<oriansj>sam_: there is also a very real possibility that maintaining bootstrap chains outside of functional package managers might already be an impossible task <oriansj>which brings about the very hard question about what that means for more traditional distros such as Debian and Gentoo <stikonas[m]>For gentoo bootstrap chains are not that much harder to write. There is a bit of issue with availability of old packages but I don't think it's inherently due to not being functional <oriansj>well can you imagine a package manager that isn't functional but also doesn't have the lack of availability of old packages problem? <sam_>I think with slotting we can manage at least some of it <sam_>the issue is just directing things which need $lib to find it <sam_>with pkg-config it gets a lot easier ***ChanServ sets mode: +o oriansj
<oriansj>sam_: but the default lifecycle of the distro would be to create new gaps in the chain, so one would spent a growing amount of time dealing with the new issues that arise. <aggi>meanwhile continued detangling from GNU within the dependency graph... toybox seems to cover most crucial userspace parts <aggi>there isn't any libressel/openssl dependency remaining, i'll replace ncurses with sabotage linux curses <aggi>however, an important difference, at this stage within the bootstrapping procedure of yours: i am aiming for a fully capable development system, instead of any intermediate bootstrapping artifact <aggi>as a consequence, with GNU-buildsystem/toolchain removed, i am missing some crucial components still, which require a manual rewrite of their makefiles <oriansj>aggi: would clang be a valid option for you? I ask because I don't think rust can be bootstrapped by less than GCC or Clang. <aggi>oriansj: no; llvm is written in c++ <oriansj>well let us hope cproc and qbe is up to the task of building mrustc <aggi>i am not aiming for any bootstrapping path arriving at rust <aggi>at best, i can salvage www-client/lynx (mozzila is the rust gang) linked against bearssl <oriansj>aggi: my mistake, so what critical parts still remain? <aggi>i still need to identify various builds depending on pre-generated configure/makefile, to remove/replace those or rewriting their makefiles <aggi>squashfs-tools, is one such package i want to keep, nfs-utils <aggi>i haven't assembled a list of those yet <oriansj>fair, it is easy to get lost in just trying to figure out how to bootstrap anything to look at how to get anywhere in particular <aggi>the bootstrapping path to arrive at tcc-toolchain are still very important; however that's where i stop then, roll-back to linux-2.4, and salvage a userspace which complies with acceptance criteria <aggi>btw. llvm/clang it is why i refrain from switching to BSD <aggi>from BSD i may salvage some makefiles for www-client/lynx; i think OpenBSD got it inside their base-system, and don't use GNU configure/makefile for this <stikonas[m]>oriansj: depends on the chain, so far mrutc->rust chain is not growing too big since mrustc is getting updates. On the other hand Java chain is growing longer and longer <stikonas>fossy, mihi: I think autogen is now reproducible in live-bootstrap <sam_>oriansj: well, I think it's something I care about <sam_>oriansj: and usually the dep list is not too big, but I understand your point too <stikonas>autogen build system does some legally dubious things... <stikonas>it sets file copyright date to current year... <vagrantc>numerous other projects do similar things <vagrantc>copyright assertion has nothing to do with when something is built ... <stikonas>cause I don't want build hash to change every year <muurkha>that would be legally dubious in the US before it joined the Berne Convention <muurkha>actually it could have caused you to lose the copyright <vagrantc>how does the berne convetion allow that? <muurkha>it's not that the Berne Convention *allows* it exactly <stikonas>probably berne convention just ignores copyright headers <stikonas>you don't need copyright header to claim copyright <muurkha>yeah, it's that under the Berne Convention, copyright assertions are just unnecessary <stikonas>so I guess reverse is also true, copyright header does not imply that you actually have copyright <muurkha>the Universal Copyright Convention does care about copyright assertions, but I don't think there are any countries that are UCC signatories that aren't Berne signatories anymore <stikonas>anyway, it was annoying not because of copyright claim but because it breaks reproducibility <vagrantc>well, breaking reproducibility is why i know it's even an antipattern in the world <muurkha>but I agree that the reproducibility is more relevant here :) <vagrantc>i was once blissfully ignorant of silly things like that <stikonas>it's probably better for new things, people tend to care more about reproducibility these days <stikonas>there are fewer cases of e.g. using __DATE__ or __TIME__ in the sources <muurkha>yeah, 20 years ago reproducibility was rarely a consideration at all