On Fri, Jan 08, 2021 at 11:30:21PM +0800, Shengjing Zhu wrote:
On Fri, Jan 8, 2021 at 11:17 PM Alberto Bertogli
<albert...@blitiri.com.ar> wrote:
On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:
>On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
><albert...@blitiri.com.ar> wrote:
>> But those issues are not made worse by allowing golang-google-protobuf
>> to go in, right?
>>
>
>Let golang-google-protobuf go in is one thing, it's not difficult.
>However without golang-goprotobuf 1.4.x it's not useful currently. But
>it will be changed if upstream has switched to golang-google-protobuf
>only.
But IIUC that's what foka@'s lastest changes do - now the two packages
are independent so golang-google-protobuf can go in?
This would unblock:
1) Some upstream packages that have upgraded to the new library and are
using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate
pb.go as part of the build (without needing grpc).
And no packages are forced into anything, since upstream needs to do the
update explicitly anyway, the ones using golang-goprotobuf will continue
to function just fine.
I understand not all problems are fixed and some things remain, but it
seems it'd be a step in the right direction since at least some packages
will be able to move forward, without causing any new
complications/regressions.
Or am I missing something?
You are right. The only concern from my side is the usefulness of
golang-google-protobuf without upgrading golang-goprotobuf to 1.4.
If some packages are already ready for using golang-google-protobuf
solely, sure we should try.
Yeah, the reason I'm personally interested in this is I have one package
I'm upstream for (chasquid) in this situation. I've already done the
required patching and is blocked on this package.
I am also waiting on the change to move other projects forward for the
same reason :)
Let me know if there's anything I can do, or how can I help!
Thanks again!
Alberto
