Re: Advice needed to break dependency stalemate

[Peymaneh <peymaneh@posteo.net>]

Hi

Am 22. Dezember 2022 08:00:36 MEZ schrieb Daniel Swarbrick <dswarbrick@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?

Peymaneh