Hello, Am Wed, Aug 20, 2025 at 07:16:45PM +0200 schrieb Simon Tournier: > Somehow, if we remove these Clang compilers, why do we keep all these > GCC compilers?
I have nothing against removing old gcc compilers; but GCC is GNU and clang is not (it might even be anti-GNU), so I would rather remove clang than gcc packages. > One cannot be back from a (summer) break and bang some packages that one > rely on had been removed because it’s productive summer for a peer. :-) All of the removed packages did not build anymore since the core-packages merge (well, almost - I also removed building llvm versions when the corresponding clang did not build). So if you relied on them, it would have been bad luck anyway - the only practical difference is that the junk is not lying in our front yard anymore. And in this, I have strictly followed the deprecation policy in the manual (which was added before the introduction of GCDs, but of course it could be changed again, this time by a GCD). So this is the real major difference between clang and gcc - as far as I know, the old gcc versions still build. Again practically speaking for people who want to use the old compilers there are a few options: - Use "guix time-machine", to a commit not before my removal of the packages, but before the merge of core-packages. - Repair and reintroduce the removed packages. The request for removal had been around for one month without anyone stepping up to repair the packages. But it is not too late for people coming back from vacation; the code can be copy-pasted from a checkout preceding the removal, and new patches can be added. On a more general level, as I have probably said a few times already, I think we need to improve the quality of our distribution, and for me that means working towards a 100% buildable distribution (and fresher packages). It will save build farm resources for packages that we already know to fail. And it enables us to see what breaks when making a change, by statelessly looking at what is broken, because almost by definition it worked before. (Right now I am working on updates where "guix build -P 1 updated-package" fails before and after the update; and I wonder whether to update or not.) Looking at QA, we have about 35000 packages, of which about 96% build on master for x86_64. This means that for the goal of 100%, we need to remove about 1400 packages... At the current rhythm, that will take years. (Of course, sometimes it may be possible to repair a key package somewhere in the middle and gain a lot.) Andreas
