Re: grpc transition
On Thu, Jun 6, 2024 at 9:33 AM Reinhard Tartler <siretart@gmail.com> wrote:
[...]
> So how do we get out of this mess? Unless we want to break (read: remove from testing/unstable) quite a large number of packages, I would suggest to introduce:
>
> * src:golang-google-genproto-apiv1 which is essentially a rename of the package golang-google-genproto we have currently in sid. This contains the fundamental types for googleapis and protobuf compiled with golang/protobuf@v1.3 and thus implements the APIv1
> * src:golang-google-grpc-apiv1 which is essentially a rename of the package golang-google-grpc we have currently in sid. This is built against the golang-google-genproto-apiv1-dev binary package (which comes from src:golang-google-genproto-apiv1) and serves as a stop-gap for existing applications that are not ready to be ported to APIv2.
>
> With those packages in place, we can then:
> * Upload src:golang-google-genproto from experimental to sid
> * Update src:golang-google-grpc from experimental to sid
> * Fix packages that FTBFS by either updating them to newer upstream versions that compile against protobuf APIv2, or update their build-depends to build against the APIv1 versions.
>
These apiv1 packages are going to cause a mess as well. Because the
old and new versions are the same module, they will conflict with each
other, just like the golang-github-golang-protobuf-1-{3,5}-dev
packages. An application can only use one at a time.
Moreover, if a package is compatible with
golang-github-golang-protobuf-1-3-dev as runtime, it should (in
theory) be compatible with golang-github-golang-protobuf-1-5-dev.
However if a package can use apiv1 pb.go files, it can't use apiv2
pb.go files, which looks worse then the runtime dependencies.
--
Shengjing Zhu
Reply to: