Draft: dev-libs/protobuf version bump, also other packages (Python, Ruby, Java)

[thican]

This is a draft, for current new versions of Google’s protobuf.

Most tests are failing, also installation for some packages, and lack the updates at least for Ruby and Java.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-17 00:57 UTC Newest commit scanned: 13d96ad6dc14c3f59fa827af181492c15b0d61df Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/1263505fce/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-18 19:36 UTC Newest commit scanned: 58c1f08f3027bd6fc28aefc931de667cb4c6be66 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/f011d7732b/output.html

[vaukai]

@thican jfyi protobuf-java is in https://github.com/gentoo/gentoo/pull/26066

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-20 14:41 UTC Newest commit scanned: 37ad499cfd76715e765399575a9fa00cbbba6035 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/deb0aa56e9/output.html

[thican]

@thican jfyi protobuf-java is in #26066

Hello @vaukai. Thanks for your notification, I didn’t see your PR before I worked on this.

As @Arfrever raised in comment #26066#issuecomment-1166321500, we indeed need to bump the main package and the other packages at the same time. Can I then cherry-pick, and rework if required, your commit, please? I will still keep your mention in the commit message, of course.

[vaukai]

we indeed need to bump the main package and the other packages at the same time.

@thican Could you pls explain this need? From Java perspective I don't see any reason for that. protobuf-java-21.5 is fine with existing dev-libs/protobuf-3.19.3 and pkgdiff against upstream is very good.

[thican]

Hi @vaukai, In fact, I have no idea if this is a true dependency, but when I look at the ebuild from your commit, I notice it pulls a dependency to dev-libs/protobuf:

SLOT="0/30"
../..
BDEPEND="dev-libs/protobuf:${SLOT}"

Based only on this information, I think it requires to keep a uniformity in packages version.

Or, in case there is no build dependency with the parent package, then I guess we can discard this relation and simply bump this Java package. I didn’t test yet the Java package, not done fixing issues with the previous ones.

[vaukai]

Hi @vaukai, In fact, I have no idea if this is a true dependency, but when I look at the ebuild from your commit, I notice it pulls a dependency to dev-libs/protobuf:

SLOT="0/30"
../..
BDEPEND="dev-libs/protobuf:${SLOT}"

Based only on this information, I think it requires to keep a uniformity in packages version.

Why do you think is uniformity in package ${SLOT} not sufficient?

Or, in case there is no build dependency with the parent package, then I guess we can discard this relation and simply bump this Java package. I didn’t test yet the Java package, not done fixing issues with the previous ones.

previous version? protobuf-java-3.19.3.ebuild is a mess, lots of classes missing, poor quality. And without packaging truth you won't have a chance to enable tests.

[thican]

With branch 3.21, the slot is 0/32 for parent package. Here from the compilation of my up-to-dated ebuild:

% command ls -1 /var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so* 
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so.32
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so.32.0.5

I don’t see where in the code the subpackage for Java is using a different slot, and I think it's pretty obvious the package is API depend of its parent package.

I think it’s better if you can provide the proof where the Java subpackage is API independent. I can’t test right now your package, I will see later.

[vaukai]

With branch 3.21, the slot is 0/32 for parent package. Here from the compilation of my up-to-dated ebuild:

% command ls -1 /var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so* 
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so.32
/var/tmp/portage/dev-libs/protobuf-21.5/image/usr/lib64/libprotobuf.so.32.0.5

I don’t see where in the code the subpackage for Java is using a different slot, and I think it's pretty obvious the package is API depend of its parent package.

Are you saying protobuf-java-21.5:0/30 gets in trouble once dev-libs/protobuf:0/30 gets removed? Agreed, then it need a slot bump.

I think it’s better if you can provide the proof where the Java subpackage is API independent. I can’t test right now your package, I will see later. Sorry, tests are not enabled truth still missing.

[thican]

I think it’s better if you can provide the proof where the Java subpackage is API independent. I can’t test right now your package, I will see later.

Sorry, tests are not enabled truth still missing.

Sorry I don’t understand your statement.

[vaukai]

Sorry, tests are not enabled truth still missing.

Sorry I don’t understand your statement.

See the test dependencies here

[vaukai]

[...] think it's pretty obvious the package is API depend of its parent package.

The only place where "parent package" is used is https://github.com/gentoo/gentoo/pull/26066/files#diff-a643c80116711a95135940c5c1ac6f417399c643b43cc8f75f21c8617535a7f9R60-R71

[thican]

Sorry, tests are not enabled truth still missing.

Sorry I don’t understand your statement.

See the test dependencies here

Okay now I understand what you mean, you were talking about com.google.truth for test phase. More important about our conversation, the Java package doesn’t require the parent package to be compiled:

Compile Dependencies (0)

So, I guess the Java package is now independent of its parent, then I guess we can remove it inside the BDEPEND variable.

Anyway, #26066 is still your PR, I won’t touch it. :-)

[thican]

[...] think it's pretty obvious the package is API depend of its parent package.

The only place where "parent package" is used is https://github.com/gentoo/gentoo/pull/26066/files#diff-a643c80116711a95135940c5c1ac6f417399c643b43cc8f75f21c8617535a7f9R60-R71

I didn’t see your message when I submitted mine. So, I guess we in fact need it, because from just reading it, I don’t think there is an executable in ${BROOT}/usr/bin/protoc during the Java package compilation. Otherwise you will need to compile the base package just to enable the Java part; it’s obviously then better to enable the parent one in the system.

What do you think?

[vaukai]

What do you think?

Sorry for crossing messages. We're finally getting to the point here. Indeed the protobuf-java ebuild needs the parent package's executable in BDEPEND, but the exact version and SLOT seem not so important. From my experience protobuf-java-21.5 compiles fine with executable of dev-libs/protobuf-3.19.3 and the pkgdiff with upstream's jar file is very good.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-21 19:36 UTC Newest commit scanned: 5f0be4c5331703d507646f1a71c3ac794df2e020 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/b7c256edbf/output.html

[thican]

Okay now I understand a bit better the instructions for Java packages, and I see why it was unnecessary to provide instructions for compile and install phases (specially when I wrongly put compile instructions in the prepare phase…). Let’s continue tomorrow, shall we? I still didn’t finish the Ruby part. I wish it could be also reviewed by some Gentoo maintainers.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-21 20:37 UTC Newest commit scanned: aa41cd88f75225f7aab33c364ac2e7b0ccd6af8c Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/86701beb35/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-21 20:51 UTC Newest commit scanned: 0486eda1140bf33decf605d81498b39e9a43b354 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/6ca7a8f3f9/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-23 22:32 UTC Newest commit scanned: 3f6bdcadf43deb61da0a4a21a9614adb00248d46 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/3daa99d4aa/output.html

[vaukai]

@thican One more question: What is the benefit of adding old dev-java/protobuf-java-3.20.1? Is there any consumer of that old version which would fail with the latest version? If not, you'd better drop it.

[thican]

Hello @vaukai,

@thican One more question: What is the benefit of adding old dev-java/protobuf-java-3.20.1? Is there any consumer of that old version which would fail with the latest version? If not, you'd better drop it.

I prefer to let to the users the choice with the current last versions for the three last branches, 3.19, 3.20 and (3.)21 (note: there is 3.19.4); therefore the subpackages should also be available for the same matching versions. For example I am one of the consumer of the 3.20 branch, at least for the Python package :-)

Once the branch is old enough, same for 3.19, we will discard simply them.

[vaukai]

I prefer to let to the users the choice with the current last versions for the three last branches, 3.19, 3.20 and (3.)21

In fact, the reverse dependency (I am only aware on one single) will only use the highest stable version (unless it's masked by a user ), meaning lower versions are completely useless, speaking here only for the Java part.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-08-30 20:11 UTC Newest commit scanned: 49bd755e052a8e506bee283b610af8ada4bdb92f Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/ea2f562879/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-09-04 22:22 UTC Newest commit scanned: d58aa87a0417bc7c122ed00546eac77c2887abe4 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/60b01ad20e/output.html

[thican]

I just rebased then pushed this MR, but I noticed this is pretty much useless.

Done anyway, in case of.

[thesamesam]

I don't think it's useless -- we still need to do Ruby and it looks like you've made some additional changes to the other ebuilds we should sync.

EDIT: And there's some more useful changes on top, actually.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-09-04 23:42 UTC Newest commit scanned: 17693239493746d79429c98b3b83b71d7ed31c50 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/61944afaa6/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-09-07 17:37 UTC Newest commit scanned: a61b6c59ca2c8db4d5259e6b0be5f6f946a17b5d Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/cb6bf90c26/output.html