Building bazel 6.5.0 using bazel tag has dependency on future version

[the-moog]

Description of the bug:

The repo at tag 6.5.0 has a .bazelversion 7.1.1. This is an issue as I'd have to build bazel 7.1.1 - This does not exist on the Ubuntu LTS 22.04 I am using. Corporate policy prevents sustem upgrade to newer LTS. Bazel 7.1.1 itself requires a newer version than the Bazel 3.5.1 that is supplied with that distro, rather than a suitable prior major version.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

On Ubuntu 22.04, as per instructions at https://bazel.build/install/compile-source

git clone https://github.com/bazelbuild/bazel
cd bazel
git switch -c 6.5.0
bazel build //src:bazel-dev

Which operating system are you running Bazel on?

Ubuntu 22.04 LTS

What is the output of bazel info release?

WARNING: Output base '/usr2/uname/.cache/bazel/_bazel_uname/cbc5c4db694080356e592e6fd8e27782' is on NFS. This may lead to surprising failures and undetermined behavior. Starting local Bazel server and connecting to it... INFO: Reading rc options for 'info' from /usr2/uname/localwork/tp_opensource/bazel/.bazelrc: Inherited 'common' options: --enable_platform_specific_config --check_direct_dependencies=error --experimental_downloader_config=bazel_downloader.cfg --incompatible_disallow_empty_glob ERROR: --check_direct_dependencies=error :: Unrecognized option: --check_direct_dependencies=error

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

n/a

What's the output of git remote get-url origin; git rev-parse HEAD ?

https://github.com/bazelbuild/bazel
963434ad6928b1d78ca60a6a55a006a9c7b41023

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

n/a

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

I am trying to build an older version as Verible uses v5...v6 (or v7 with with some pain)
So, I have no intention of making bazel system wide.

After failing to build 6.5.0 using the Bazel method, due to the need for a newer Bazel and the errors from the .rc file, I tried building using the bootstrap method. However I immediately ran into issues (#14548) with Java versions. I guess I could go back through all versions until I find one that works, but that's a lot of effort and in any case, I can't change the system Java as that would cause a lot more issues.

Note: Corporate policy prefers that I don't d/l and run binaries unless signed, the corporation runs it's own APT repos. I can only build from verified trusted sources, and then only packages that are 'well known and understood'. How about offering snap+docker build env, or some other app overlay and/or virtual environment that can be authenticated and independent of the state of the system it's using to both run and build itself?

Note: Though I still think this is an issue, thus I am reporting it, actually I accidentally worked round this (against corporate policy - oops) as I tried the bootstrap method, which failed, it must have put a bazel-7.1.1 binary in the .cache tree, which it then found, rather than use the older system one!
(I am guessing this is as I had been looking at the Python bazelisk to see if that would help, until I realised that it did not build and just downloaded a binary. Baselisk.py did not understand the version syntax and tried the wrong URL, and so has issues, but it seems it still worked well enough to find the binary - Perhaps that d/l should be at least a non-default action, expecially for a fundamental low level tool?)

So, once the damage was done, I may as well take advantage of it. And doing that did allow 6.5.0 to build, all be it with a lot of warnings.... And it seems that it works as I was then able to build Verible and so have a means that I can document and reproduce, even if it's not exatly correct with policy. Not sure how to sell that....

Back to the issue:
I still am of the opinion that older versions should be only ever built with some baseline i.e. One Included with previous LTS or official backport, rather than the bleading edge. Usually the reason for wanting an older version is some dependency, or limitation and that same dependency more than likely exists in newer versions.

Oh. Lastly. another related issue: I subsequently noted that symlinking bazel-dev to ~/.local/bin/bazel did not work with the error
[FATAL 10:13:28.053 src/main/cpp/archive_utils.cc:72] Failed to find member 'build-label.txt' in zip file '/usr2/uname/.local/bin/bazel-dev'
However hardlinking was fine - very odd. Not sure if that is a bug, a known limitation or by design.... I can raise another issue (even if to just document that quirk) if needed.

[Wyverald]

The repo at tag 6.5.0 has a .bazelversion 7.1.1

This is not the case. https://github.com/bazelbuild/bazel/blob/6.5.0/.bazelversion correctly contains 6.2.1.

git switch -c 6.5.0

Per the docs of git switch, I'm guessing that this has the effect of creating a new branch (not tag) called "6.5.0" and switching to it. This is confirmed by your git rev-parse HEAD returning a commit on master. You should use git checkout 6.5.0 instead (you might have to do git fetch --tags first).