[Please keep 54067@debbugs.gnu.org in CC, such that other people can comment] kiasoc5@tutanota.com schreef op zo 20-02-2022 om 19:50 [+0100]: Of course updating python-importlib-metadata is the natural option, > I don't intend to submit broken patches. But I'm not sure whether > updating python-importlib-metadata will be smooth, if I run guix > refresh -l python-importlib-metadata, it says `Building the following > 74 packages would ensure 131 dependent packages are rebuilt`. It's a > lot of packages to comb through. What I'd usually do for testing is $ ./pre-inst-env guix build python-astroquery@0.4.5 vorta@0.8.3 komikku@0.36.1 [...] and verify that the builds succeeded. If their test suites are good, this should catch most issues. Python packages are typically relatively cheap to build I think, so this shouldn't take overly long. We'll have to update python-importlib-metadata anyway eventually, and it's not realistic to test each individual dependent manually. > Is there any policy on testing packages for breakage when upgrading? > Apologies, I should have asked this earlier. There's (guix)Submitting patches: 10. For important changes, check that dependent packages (if applicable) are not affected by the change; ‘guix refresh --list-dependent PACKAGE’ will help you do that (*note Invoking guix refresh::). [...] All these branches are tracked by our build farm (https://ci.guix.gnu.org) and merged into ‘master’ once everything has been successfully built. This allows us to fix issues before they hit users, and to reduce the window during which pre-built binaries are not available. (so if building the python packages locally takes too long, perhaps a temporary branch can be set up to let the build farm take care of building). Greetings, Maxime.