( schreef op zo 12-06-2022 om 14:13 [+0100]: > Seems a little risky just to avoid packaging one fork It's not about _one_ fork, it's about forks in general. And wasn't it backwards compatible? And no need the slightly risky ‘point the go-golang-org-x-crypto package at protonmail’ if it is upstreamed instead. > Anyway, I think it'd probably just drive people even further away > from distribution package management towards the "modern" (read: > insecure, bloated, and inherently flawed) stuff like Docker and > Flatpak. At some point, if people shoot theirselves in the foot by being misled by other projects, that's not something Guix can help with avoiding I think. (Unless someone wants to start an awareness campaign?) Anyway, I don't follow -- your proposal is to include all the forks where used by upstream, which leads to insecurity because: * more packages -> more complexity -> more difficult to do changes * more packages -> more packages that can be out-of-date * more forks -> more forks that might be unmaintained and hence be at risk of being known-insecure by attackers without an update available * more packages -> more packages that need to be updated -> less time for structural improvement on security * more packages -> more opportunity for malware to enter. and also: * more packages that +- do the same thing -> bloat So from here, the proposal implies making packaging in Guix worse in some aspects, such that people don't use other system's that are bad in the same aspects ... I don't think it's a good idea to start a ‘race to the bottom’ [0]. [0] https://en.wikipedia.org/wiki/Race_to_the_bottom Greetings, Maxime.