Hi, Arun Isaac <[email protected]> skribis:
> I recently came across[1] this article that using git as a database for > package managers is a really bad idea. The article argues the point with > examples from many other package managers including Nix. Guix is also a > heavy user of git of course, and perhaps we should be worried. > > https://nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html I saw it as well. Yes, asymptotically Guix could be hitting problems similar to what Nix has (and in fact ‘guix pull’ is already slow especially the first time because it ends up cloning this big repo). There are several ways forward I think, from keeping fewer packages in Guix proper and moving peripheral packages to channels (still maintained by Guix, but as separate repositories), to allowing Guix to operate on a compiled form of its package database (similar in spirit to the “package cache” created by ‘guix pull’). No rush, but we should start thinking about it! Ludo’. PS: I had a “state of Guix” session at Guix Days 2023 where I identified the following threats, which are still valid: - Rust! Rust in Linux! Rust everywhereeeeee! we’re doooomed! - more generally: growing packaging complexity - too many contributions! too few committed volunteers! + losing excellent contributions & talented people - too many packages! is indefinite growth viable? 🤔 + 2025: ~guix pull~ requires 10G of RAM and runs in 15mn at best - sysadmin doomsday: small bus factor on sysadmin - becoming a forever-niche project - 2025: keyboard needs proprietary firmware
