Hi, On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" <arne_...@web.de> wrote:
> Please don’t remove packages that are broken on the CI. I often had a > case where no substitute was available but the package built just fine > locally. This is not a perfect situation (nicer would be to track why it > doesn’t come from CI — sometimes it’s just a resource problem on the > CI), but if you removed a package I use that would break all updates for > me. Well, I do not think that any policy will mark a package for removal on the first build failure. However, if the same package is still failing after several X <duration> or attempts, it means something is wrong. Marking it as a candidate for removal implies: 1. check if the failure is from CI when it builds locally, 2. keep a set of packages that we know they are installable. For instance, ocaml4.07-* packages are failing since more or less April. https://data.guix.gnu.org/repository/1/branch/master/package/ocaml4.07-ppxlib/output-history Does it make sense to keep them? For another example, some perl6-* packages are failing since… 2021. https://data.guix.gnu.org/repository/1/branch/master/package/perl6-xml-writer/output-history Does it make sense to keep them? The usual situation is that CI is able to build the packages. The set of packages that CI is not able to build is very limited and it is the exception. Having a rule to deal with the regular broken packages appears to me a good thing and very helpful to keep Guix reliable. And that rule cannot be based on rare exceptional cases. > If a change in packages breaks my manifest, that is extremely painful. Yeah, and such rule for dealing with broken packages will be helpful for detecting such change and so avoid such situation. Cheers, simon
