On Sat, Jul 13, 2024 at 2:57 PM Simon Josefsson <si...@josefsson.org> wrote:
> 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 :)
>
I'm really glad to hear that an experienced and active DD like you
is volunteering to help with this migration. That's really much
appreciated.
As far as I can tell, I've managed to execute this transition in
"experimental"
for all packages that are currently in testing and are affected by
the containerd migration.
It is possible that I missed packages, so I'd appreciate some
double-checking
of my work.
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.
>
That sounds very goal oriented if we agreed on the goal being
"get podman 5 into testing asap". This is clearly one of my goals.
The approach that you describe above comes with risk:
- Does uploading packages that start this transition cause unpleasant
surprises?
- Does this break packages that we miss to testbuild?
- Does this slow down other, unrelated ongoing transitions?
- Does this require major upstream version updates to other packages (and
if so, are the maintainers of affected packages available to quickly react
and help with restoring those packages)?
- Do we need to temporarily remove other packages to ease this migration?
I personally believe the benefits of achieving the goal outweighs the risk.
I
do hope the Debian release team agrees and is comfortable with me starting
the
migration by uploading packages that are currently in experimental to
unstable,
and are able to advise and help with hints to britney to minimize the
disruption.
My pitch would be to start with sourceful uploads of (and in that order):
- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2
- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency
- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups
- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image
- golang-github-containers-common
- golang-github-containers-buildah
- libpod
Yes, that is a long list. I think we can do it, but I'm also
interested in minimizing surprises, smooth transitions, and would like to
mititgate
the risks mentioned above with coordination and thinking this through.
Thanks so much for your assistance!
--
regards,
Reinhard
