Release bazel installer for arm64

[odidev]

Hi Team,

Thank you for releasing bazel binaries for arm64 in the 3.4.0 release. Now we have bazel-3.4.1-installer-linux-x86_64.sh available for x86_64. Is it expected to have bazel-3.4.X-installer-linux-arm64.sh for arm64 in future ?

[mattsplats]

Any progress on this? Thanks!

[odidev]

Hi Team,
Is there any progress going on in this activity?

[mattsplats]

Just following up, thanks!

Related:
Docs for arm64 install: #11994
Missing arm64 in apt repo: #12223

[philwo]

Hello, I'd like to better understand your use-case.

Bazel is a single binary that can just be executed, so an installer or Debian package isn't really necessary to install it - could you please explain why you'd prefer these instead of just downloading and running the binary? :)

[mattsplats]

I think the intent here is if there's a use case/need for this install script on x86, it should also be available for arm64.

Being able to build the binary for your distro also means you're not dependent on anything specific to the release binary (e.g. shared libraries).

[philwo]

@mattsplats I agree that if we provide it for one architecture, we should provide it for all applicable architectures. 👍

In order to understand whether it's a good use of our resources, I would like to understand the general usefulness of the installer script and Debian packages that we provide (also for x86_64). The installer script and Debian package do nothing special - they simply wrap the same binary that you can download anyway and put it in some place, so I wonder if we could just stop providing these artifacts and ask people to download and use the binary directly.

I'm not sure I understand how this is related to being able to build the binary for your own distro. This is supported and will of course stay that way (we have an integration test that ensures you can bootstrap Bazel on each platform we test on via the compile.sh script and also build it from source if you have an earlier version of Bazel already). :)

[mattsplats]

Apologies, I assumed the install script compiled from source.

Removing the script and Debian package makes sense, as otherwise you'll need to maintain them for multiple arches. The only objection I've heard is that a package install could automatically update Bazel with your other dependencies (e.g. apt upgrade), but perhaps Bazelisk should be the recommended solution for this.

[jwnimmer-tri]

The Debian (Ubuntu) package is more that just the raw bazel binary that's provided on each releases' github page.

The Debian package also includes the bash and zsh completion files [1,2], as well as the /usr/bin/bazel bash script that implements the tools/bazel project-specific hook [3].

I think the installing the shell completion files system-wide is an important part of the user experience that's missing from the single-binary release mechanism (bazel-5.3.1-linux-arm64 or bazel-5.3.1-linux-x86_64). The shell-binary release installers like bazel-5.3.1-installer-linux-x86_64.sh do provide the shell completion files, but they are not activated system-wide, even if bazel is installed into /usr/local; the installer prints out instructions for how each user on the system can add the completion hooks to their personal bashrc file one by one.

The versioning script at [3] is more of a mixed bag. It would be fair to argue that the $USE_BAZEL_VERSION hook there is less helpful than bazelisk, so it's OK to lose that feature in most cases. It's less clear to me that dropping the tools/bazel hook is satisfactory. That hook can be used to prepare the build environment outside of the scope of bazel itself, and so should probably remain a core feature supported by all release mechanisms.

On the question of what would be the most worthwhile for the Bazel Team to invest in... I would actually advocate for doubling down on bazelisk, and dialing back the others:

• Ship official[4] Debian packages for bazelisk, linked from via the bazel.build website, and regularly deployed into the official Bazel apt site.
• Ship official bash installers for bazelisk (bazelisk-installer-linux-x86_64.sh) via the bazel.build website.
• Both of the above should incorporate support for shell completions and tools/bazel hooking.
• Continue to publish raw binaries each release (bazel-5.3.1-linux-x86_64 etc).
• Stop publishing anything beyond raw binaries (debian packages, bash installers, etc.) -- with suitable notice ahead of time.

By simplifying the install process to just be "install bazelisk" and then letting bazelisk fetch the actual binaries, each individual bazel release can trim down its responsibilities to just the single binary.

---

[1]

bazel/scripts/zsh_completion/_bazel

Line 1 in f71bbcf

#compdef bazel

[2]

bazel/scripts/BUILD

Line 7 in f71bbcf

name = "bash_completion",

[3]

bazel/scripts/packages/bazel.sh

Lines 19 to 21 in f71bbcf

	# This is a script which can be installed as your "bazel" binary instead of the
	# real Bazel binary. When called, it tries to determine and run the correct
	# Bazel version for a given project and forwards all arguments to it.

[4]

As it stands, the https://bazel.build/install/ubuntu page says "Use bazelisk" which links to https://github.com/bazelbuild/bazelisk/blob/master/README.md which has almost no instructions for Ubuntu users, just "download something from the releases page and add it to your path". Besides just being confusing, that loses out on the customary Ubuntu practice of automatic (security) upgrades via an Apt site.

[jwnimmer-tri]

See also bazelbuild/bazelisk#563. I'm hoping to push forward on providing bazelisk as *.deb package, which (as I noted above) would hopefully reduce the pressure to ship all Bazel versions as separate packages on all architectures.