On Sat, Apr 26, 2025 at 10:55:57AM +0200, Paul Gevers wrote: > Control: tags -1 moreinfo
I intentionally leave moreinfo in place as I hope for a better answer from Fabian. > Which set are we talking about, can you create a list? (Please remove the > moreinfo tag when you reply). The initial mail included a "source-packages" attachment listing 679 binary packages. I expect that most of them are built by distinct source packages. > For that final binNMU round you're talking about, is there already an > established way to determine what's needed? Like for other languages we also > don't just do rebuild because we can (maybe we should, but then I think > earlier in the release cycle), so I think we'd only want rebuilds for known > issues that are worth fixing, not just for newer versions (which could > trigger subtle bugs we haven't spotted yet). I fear we are not talking about binNMUs here. From a debcargo point of view, debian/control is an export format, but from an archive point of view it is an input format. The thing that is being changed here is the generation of the debian/control file. Modifying it during built is a ftp master reject reason. Therefore, I expect that we will have sourceful uploads with differences here. The allowed annotation is not immediately harmful. As long as no dependency is annotated :any, it effectively does nothing. According to Fabian, no relevant :any annotations exist inside Debian at present. The problem arises when :any annotations happen. At that point we gain breakage in trixie -> forky upgrades. It doesn't even have to be Debian's own packages that issue such :any annotations. Once they exist, the next upgrade will be annoying as it ends up removing those client packages. Multi-Arch: allowed annotations are a bit like Pre-Depends and epochs. They should be unusual and therefore we recommend discussing their use with d-devel@l.d.o (see policy bug #749826). Unfortunately, debcargo issued Multi-Arch: allowed by default. Helmut
