Hello everyone,Some good news to share: having resolved some confusion with the Debian FTP team, the bazel-bootstrap package is no longer held up in the NEW queue! I'd like to thank the FTP team for the quick approval of the package after that resolution.
I'd also like to thank Jesse Chan for the great work with updating bazel-bootstrap for the 4.0.0 and 4.1.0 releases of Bazel! As you can see, I rebased those changes on the existing changes that created the bazel-bootstrap-source package. Those are now live in unstable.
Furthermore, I just uploaded a 4.2.2 version. The aforementioned changes made that an easy update. This completes the 4.x series and I'm planning to start on 5.0.0 in the next few days. There are quite a few excellent features that the 5.x series will bring to Debian and I'd like to be closer to HEAD when we're preparing the initial bazel-X package.
For that to happen (I'll update the wiki shortly) we need a few dependency updates. Off the top of my head:
google-auto-common-java to 1.1.2 google-auto-value-java to 1.8.2 checker-framework-java to 3.2.0 grpc-java to 1.41.0 (this will likely be the trickiest!) rx-java to 3.1.2There are probably some transient dependencies there as well but I haven't investigated fully.
I'm also trying to get bazel-stardoc polished up now that the bazel-bootstrap-source dependency is available. I really, really want to have a bazel-X package for the bookworm release of Debian.
So, any assistance with those dependencies (or any I missed) would be greatly appreciated! They should all hopefully be reasonably simple updates (except likely grpc-java). I'm happy to review and sponsor uploads for non-DDs.
Regarding the bazel-X package, a question for everyone out there: which version of Bazel should we target? 4.x is effectively obsolete and will be out of support during the bookworm lifecycle. 5.x, as I recall, will only last maybe halfway through bookworm's lifecycle. I'm tempted to target 6.x since I understand that should be released soon and will overlap significantly (if not fully) with the bookworm lifecycle. Does that seem reasonable to everyone? Any concerns with targeting a relatively new release?
That leads me to my final question, mostly aimed at the upstream Bazel developers. Should we still plan to have multiple concurrent versions of Bazel in Debian (with the accompanying massive increase in packaging complexity) or are newer versions of Bazel able to build source that targets earlier Bazel versions without issues? i.e. Is package foo (that was designed to build with Bazel 4.2.2 or Bazel 5.1.1) expected to build cleanly on Bazel 6.0.0? (If not, can that be fixed with relatively simple patches?)
As I plan out the implementation details of simultaneously maintaining multiple Bazel versions in Debian, it seems that it would be much better if we didn't have to do that...
Excited to get back to working on this ecosystem, and working again with all of you!
-Olek
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature