On Mon, Dec 02, 2024 at 08:14:04PM +0100, Simon Tournier wrote: > Hi, > > On Mon, 02 Dec 2024 at 14:44, Ludovic Courtès wrote: > > > This manifest is just an example. We could come up with manifests > > targeting package collections like CRAN packages, astronomy packages, > > and so on. > > Let consider that a “leaf” package is a package that does not appear > elsewhere in any other packages. Then, if there is no mistake, I count > 14143 leaf packages over 32459 all packages. > > Well, if we filter using gnu-build-system and cmake-build-system then it > reduces to 2847 packages. > > These packages are “safe” to automatically update because the only > annoyance will be users at run time. ;-) > > Somehow, the loop and type conversion are not optimized but maybe this > kind of “leaf” packages could defined and then filtered build-system per > build-system, i.e., team per team. > > WDYT? To repeat what I said on Mastodon and the impression I got from the Nix folks, if we can automate away the easy/simple package upgrades then we can spend our time on more complex upgrades that require more attention to get correct. I'm now thinking about the easy-package -> hard-package learning curve for new contributors, and I'm not sure how we'd address that. Also I don't think we should spam the bug tracker with package upgrades, so we'd have to think about something for that. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted