On Sat, Apr 26, 2025, at 4:19 PM, Helmut Grohne wrote: > 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.
Exactly. >> 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. Yes, we are talking about regenerating the source package using the updated debcargo and doing source-ful uploads. I just mentioned the binNMUs as a side note that depending on whether another run of those is done, all those packages would be binNMUed before Trixie, so an extra source-ful upload doesn't add a huge additional regression potential. The binNMU itself would not get rid of the "allowed" annotation, since the source packge containing it would be identical. > 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. Unless I missed something, the packages from my list with "allowed" have no dependencies on them annotated with :any anywhere. > 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. yeah, like I said, this was "inherited" by me and just never noticed, I am glad you did point it out and we can correct it (hopefully painlessly).
