babashka-sci-dev

lispyclouds 2022-12-12T07:31:49.212839Z

Right, but this approach could be a blocker in situations like: β€’ Some CVE or something forces us to update the underlying OS and or glibc tooling β€’ native-image starts requiring a newer glibc The approach does makes it safer in a defensive sense, but seems to me like a blocker if we get hit by things like above? The OS/glibc is our JVM here and if and when that changes, its a breaking change we need to accept? I guess at some point clojure too might need jdk 11 or something and that's the same issue like this πŸ˜… we should put this check in now, but id also like to explore ideas which solve this for a longer run?

borkdude 2022-12-12T07:37:13.112149Z

The check at least makes us aware when we upgrade libc. We can then always make the choice to violate that rule. I don’t think native image will soon require specific versions of libc

lispyclouds 2022-12-12T07:40:43.669829Z

yeah makes sense to add the check in now and also fail if its > 2.31 and see what happens. as for the glibc updates, i was referring to the release notes which said they need 2.17 or higher glibc

πŸ‘ 1
lispyclouds 2022-12-12T08:19:19.853799Z

also i guess at this point we could build a reusable lib on bb tasks or something for clojure native-image CI so that similar projects can use it and all the headache is on one place πŸ˜› i think we have uncovered a lot of pain points to abstract over?

lispyclouds 2022-12-12T08:20:00.658969Z

we have bootstrapped bb too for this πŸ˜„

lispyclouds 2022-12-12T08:21:10.589389Z

The idea being the CI its running on just sets up an agreed upon env and calls the tasks in order