Reinhard Tartler <siret...@gmail.com> writes: > My takeaway is that we need to update a large number of packages at the > same time, starting with src:golang-google-genproto > and src:golang-google-grpc. This will unblock a number of packages that are > currently in experimental, and will allow them to enter unstable. However, > this comes with the risk of breaking other packages. > > I've been chasing down the stack of dependency fairly far, but I feel I'm > reaching my capacity of how far I'm able to push this transition.
I am suffering from lack of grpc update too (for rekor and cosign), and I'm available to help do the required work here. Alas, I'm a bit at a loss how to approach this problem, as whenever I've started to look into this I reach some kind of circular dependency loop that I don't know how to resolve. If someone were to do the heavy thinking and maybe make a list of packages and versions to upload to experimental I am willing to help :) Shouldn't the process really be to take one important package, like podman, and then go through each reverse dependency that's not already in unstable and just upload them to experimental? Entering into dependency loops as it may be, but eventually reaching back to podman. If some other package stops building with the new reverse dependency, threat that as a serious bug in that separate package instead of with the new upload. Maybe we have to live with some failed builds after the upload to unstable due to circular dependencies, but shouldn't that be possible to resolve by scheduling a binnmu or simply doing another upload of the relevant package? I wish some documentation on how to approach this were available. /Simon
signature.asc
Description: PGP signature
