<zimoun>civodul: for the stable branch, yes I am currently considering it. Maybe via GuixHPC. I do not know, I have to do some stats to estimate the effort. For sure, basically if an user does not have a Guix savvy person around, it is really hard to work with it, professionnally speaking.
<civodul>do you have in mind missing substitutes, broken packages, or other things as well?
<zimoun>for now, my rule of thumb to detect broken packages is to check missing substitutes. :-)
<zimoun>what I have in mind it is: once a week, list the additions and updates, check with CI, cherry-pick.
<zimoun>it is some work to have a script and manage potential Git conflicts
<zimoun>but I think it would be worth for attracting more users from academia.
<zimoun>civodul, maybe Vagrant could tell more but for instance https://tracker.debian.org/pkg/gmsh and from my understanding, Guix is currently “unstable” (basically as for Debian, it mostly works) and I would like that Guix has a “testing”; if it works fine enough on “unstable” then it goes to “testing” which means it just works (modulo some bugs).
<mbakke>I've been considering a "stable-updates" branch for core-level (but "safe") updates such as patch releases of Python, curl, nghttp2, pcre, etc ... it would fall in between "core-updates" and "staging", and replace the "ungrafting" cycle.
<mbakke>there would still be regressions of course, but at a much more manageable level
<mbakke>this "core-updates" round we fought regressions with GCC, Python, "sanity checks", Meson, etc, all at once
<mbakke>or perhaps all those should rather be topic branches :)
<mbakke>it takes a lot of experience to determine which updates are "safe" or not
<zimoun>heh, I was typing: how do you determine what is “safe”? :-)
<zimoun>rekado: have you tried to build R using musl instead of glibc?
<civodul>it's a fine point that few people care about it seems, but one with a real impact
<zimoun>thanks for explaining. But that’s not time-machine. Because time-machine provides (or least tries hard!) the same bit-to-bit (bug-to-bug), i.e., all the build infrastructure is the same, and inspectable.
<zimoun>If Nix changes something, then Nixpkgs is different, it is hard to know where does the difference come from? Because Nix change? Because Nixpkgs? Because butterfly effect? etc.
<zimoun>And as you said, time-machine fixes backward compatibility issues. We could change some API (new new inputs style or new DSL using Wisp) without breaking the past.
<civodul>we don't pretend packages and core are loosely coupled
<zimoun>now we are saying that, I have never thought that both work as a compiler; compiling a (domain specific) language to binaries. We include the source with the compiler itself; otherwise the door is open for many issues: standard, compatobilities, etc. Since it is domain-specific, it makes sense (at least to me!) include all in the compiler.