[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Bazel work restarting



On Mon, 2022-10-10 at 15:49 -0400, Olek Wojnar wrote:
> Hello everyone,
> 
> 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?
> 

My personal suggestion is to keep 5.X for a while, since
(1) tensorflow master branch uses bazel 5.3.0 currently
https://github.com/tensorflow/tensorflow/blob/master/.bazelversion
(2) archlinux build their tensorflow package using bazel 5.3.1
https://archlinux.org/packages/community/x86_64/bazel/
Based on its reverse dependency, you can see that people needs
bazel mostly due to tensorflow.

> 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?)
> 

IIRC, as long as bazel does not break its API/CLI, a slightly
higher bazel version is ok to build packages. That said, whether
this could be successful in 6.0.0 completely depends on how much
interface the upstream does break.

Based on our current contributor bandwidth I think it is not
necessary to maintain multiple versions of bazel. It is not as
widely used as autoconf. Simply filing an RC bug for a reverse
dependency if the build got broken would be a good option for
a while.

> 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...

Yes, better not to do that. It's not like autoconf afterall.

> Excited to get back to working on this ecosystem, and working again
> with 
> all of you!

Thank you for working on this!

> -Olek


Reply to: