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

Reply via email to