It can be fixed with regeneration, in an ugly way. I patch the generated file after it's been generated, I didn't find a better solution... It could be a bug upstream. However upstream did a major code refactoring to go to version 1.4, so there's no fix that can be cherry-picked from their git history.But that's not the point. My concern is that if I rebuild the package with code regeneration, the diff with the current package "golang-goprotobuf-dev 1.3.4-2" is much bigger, and I'm afraid that it breaks things. On the other hand, if I just disable code regeneration, the diff with 1.3.4-2 is really minor.So I thought that, given the timeline, it was better to make as little change as possible to this package.On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu <email@example.com> wrote:On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
> Hello Go Team,
> in order to solve #977652, I would need to modify & rebuild the package
> The issue is that this package has many reverse build deps, as you might
> know already:
> $ build-rdeps golang-goprotobuf-dev
> Found a total of 218 reverse build-depend(s) for golang-goprotobuf-dev.
> I did some work already, and it seems that the least invasive way to fix
> #977652 is simply to disable code regeneration and rebuild
> golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
> will then be very minor. I can post a diff if anyone is interested.
> My question is: is it OK to update this package now, or is it too risky,
> and should I wait for after the freeze then?
I think minor fix is ok. But OTOH I think we want to keep regenerating files.
Can it be fixed with regeneration?