Hi Vladimir, We would like to upgrade bazel-bootstrap to 9 at some point. But currently it is not doable because the protobuf version is too old in Debian unstable. The protobuf in Debian right now is just suitable for 7. Not 8 or 9. Otherwise I've already upgraded it.
In the meantime, I think we could check if it is possible to backport it to bazel 7. For example, android-cuttlefish needs bazel 8 at least. But we still build it with bazel-bootstrap (which is 7) right now. The major difference between 7 and 8 is that 8 has something called "macro(...)". So you can check if the rules are using that. And how many times it uses it. If it uses too many macro(...) then we should give up. But if it only uses it a few times, here is the patch for it. https://github.com/google/android-cuttlefish/commit/6ff0b89070e7fe71c21a9db5a61ad27a7c75f5d1 As you can see in this commit we tried to implement a macro(...) for bazel 7 if macro is not available. In android-cuttlefish we also have smaller patches that port bazel-8 to bazel-7 too. So if the change is not huge, this might be a temporary solution. Until we get bazel-8 or 9 uploaded to Debian. Versioned packages for bazel are good but I'm not sure what is the correct way to maintain those different versions right now. Because bazel-rules-* also need to bind to certain bazel versions. If you look into bazel-rules-* you'll see that those are not the latest too. I tried to pick the version released around 2023 so that they won't use macro(...). Upgrading bazel-rules-* to the latest version you'll see it break the builds just because of macro(...). Yours, Paul On Wed, Sep 23, 2026 at 10:31 AM Vladimir Petko < [email protected]> wrote: > Hi Emmanuel, > > Thank you!!!!!! > > I did come across the paper that describes an interesting approach. It > claims that we can have reproducible results by having the LLM harness > generate refactoring recipes[1] rather than directly patching the > source code. This also saves tokens, as a single recipe (such as > dropping all instances of the dokka plugin) can be applied across > multiple packages. > > I was also wondering if moving from maven.rules / maven.ignoreRules > to publishing relocation POMs could simplify things. This allows the > agent to work directly with the prepared Maven repository and the > source tree without struggling with the Gradle plugin that rewrites > the artifact coordinates. > > The Kotlin DSL requires Kotlin that requires Intellij IDEA Platform > that requires Bazel. Bazel was recently upgraded to 7.7.1 (which is a > great news) , but we need 9 for Intellij IDEA ;( Since those are not > backwards compatible I was wondering if the goal is to have 9 as the > bazel-bootstrap or we will need a versioned package? > > Best regards, > Vladimir > > [1] https://huggingface.co/papers/2606.24446 >
