On Thu, Dec 22, 2022 at 07:54:49AM +0000, Peymaneh wrote: > Hi > > Am 22. Dezember 2022 08:00:36 MEZ schrieb Daniel Swarbrick > <dswarbr...@debian.org>: > >Hi, > > > >On 22.12.22 16:30, Shengjing Zhu wrote: > > > >> So I think we can follow upstream, which means: > >> > >> + still uses protoc-gen-go 1.3 to regenerate the client_model, ensure it > >> only > >> imports github.com/golang/protobuf. This is to make sure other packages > >> that > >> still depend on old protobuf won't break. > > > >That is not as easy as it sounds, as you're probably already partly aware > >from bug #1026696. I'm yet to find a way to prevent the regenerated > >metrics.pb.go from importing google.golang.org/protobuf, due to the changed > >behaviour of protoc >= 3.14. > > > >> + declare golang-github-prometheus-client-model-dev depends on > >> golang-github-golang-protobuf-1-3-dev | > >> golang-github-golang-protobuf-1-5-dev. > >> + other prometheus packages can use golang-github-golang-protobuf-1-5-dev > >> in build-depends. > >> > >> As a side node, please don't use golang-github-golang-protobuf-1-3-dev and > >> golang-google-protobuf-dev together when building prometheus. They are not > >> compatible. > > > >I'm happy to use golang-github-golang-protobuf-1-5-dev now that it is > >available in sid, as it means I can drop two patches. However, it's still > >not clear how migrate to it, since we have a chicken-egg problem with > >prometheus-common and prometheus-client-golang, as they depend on each > >other. As soon as I update one of those packages to B-D on > >golang-github-golang-protobuf-1-5-dev, it will conflict with the > >golang-github-golang-protobuf-1-3-dev which is B-D'ed in the _other_ package. > > > > Maybe it is an option to vendor one of the prometheus packages in the other > respective package to get rid of the build dependency, and drop the vendored > files and reintroduce the circular dependency in a later revision once they > do not depend on go protobuf 1-3? >
I'm very concerned about such _vendor_ advise without investigation the situation first. prometheus libraries are used by *many many* packages. Upstream has the opinion that client_model is using protobuf v1, since they haven't decided how the breaking changes would impact. If you want one day they don't depend on protobuf 1.3. Please help such https://github.com/prometheus/common/issues/317