[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Plans for golang-goprotobuf to unstable?



On Sun, Jul 10, 2022 at 3:42 AM Mathias Gibbens <mathias@calenhad.com> wrote:
>
> On Thu, 2022-06-16 at 01:06 +0800, Shengjing Zhu wrote:
> > On Thu, Jun 16, 2022 at 12:49 AM Domenico Andreoli <cavok@debian.org>
> > wrote:
> > >
> > > Hi Pirate,
> > >
> > > I'm attempting to get gnostic updated but it needs a newer version
> > > of golang-goprotobuf-dev.
> > >
> > > I see you already packaged 1.5.2 and uploaded it to experimental.
> > >
> > > For what reason did you go for experimental?
> >
> > https://release.debian.org/britney/pseudo-excuses-experimental.html#golang-goprotobuf
> >
> > > Do you have any plan for uploading it to unstable?
> > > Is there anything I can help you with towards this goal?
> > >
> >
> > https://lists.debian.org/debian-go/2021/08/msg00061.html
> >
> > Probably the best way forward is to create a new package.
> > https://lists.debian.org/debian-go/2021/08/msg00077.html
> > But it needs to be figured out whether they need to be coinstallable?
> >
> > And there are other packages like go-grpc that are stuck because of
> > this chaos.
>
>   We're now just a little over six months from the bookworm freezes
> beginning [1]. I think we need to make a decision on what steps to take
> to ensure that there will be enough time to complete the protobuf work
> well in advance of the freeze so things can be in a good state for the
> bookworm release.
>
>   I don't know how the wider go ecosystem has been adapting to the
> breaking changes, or what other distros are doing, but maybe that could
> provide some guidance for what we do in Debian.
>
>   For fun, this weekend I rebuilt all the reverse dependencies of
> golang-goprotobuf-dev, v1.5.2 that's staged in experimental. Of the 258
> rdeps, only 24 failed to build. Of those:
>
>   * 12 packages legitimately fail to build with the updated golang-
> goprotobuf-dev (notary, continuity, golang-v2ray-core, golang-github-
> grpc-ecosystem-grpc-gateway, golang-github-grpc-ecosystem-go-grpc-
> middleware, mirrorbits, golang-github-hashicorp-go-plugin, golang-
> github-gin-gonic-gin, golang-gopkg-rethinkdb-rethinkdb-go.v6, nomad,
> golang-github-rootless-containers-proto, golang-github-grpc-ecosystem-
> go-grpc-prometheus)
>
>   * 8 packages have existing FTBFS issues (with filed bugs) in
> unstable, unrelated to the updated golang-goprotobuf-dev (prometheus-
> tplink-plug-exporter, golang-github-go-chef-chef, golang-github-viant-
> toolbox, debiman, cadvisor, prometheus-homeplug-exporter, golang-
> github-manyminds-api2go, gitlab-ci-multi-runner)
>
>   * 1 package is a legitimate candidate for removal from the archive:
> golang-gopkg-gorethink-gorethink.v3 (no rdeps in main)
>
>   * 3 packages have versions staged in experimental that build properly
> (gobgp, gitaly, golang-google-grpc)
>

I should have mentioned it earlier. For this particular transition
(google/protobuf 1.3 -> 1.4+), ratt is not enough. For example,
containerd will panic at runtime (root cause is #975431). The
incompatibility is not at compile time, but at runtime.

For safety,  I think google/protobuf (>= 1.4) should mark Breaks:
golang-gogoprotobuf-dev.  Otherwise all package maintainers should
verify if the package is still functional after rebuilding.

-- 
Shengjing Zhu


Reply to: