On Thu, Jun 6, 2024 at 9:33 AM Reinhard Tartler <[email protected]> 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/[email protected] 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
