They seem to be mostly interested in packaging bazel *for* Debian, while I'm more interested in building packages *with* bazel. Currently I'm mainly concerned about my own software (where with my other hat I am the developer, as well as the maintainer), but this is going to show up more as bazel use becomes more common...
On Thu, 9 Jun 2022 at 00:38, M. Zhou <lu...@debian.org> wrote: > Hi David, > > Debian has a group of people working on bazel packaging. > https://lists.debian.org/debian-bazel/2022/06/threads.html > And bazel itself has been a years-long pain for tensorflow packaging. > > I'm not following the updates for bazel packaging, but you > may browse the packaging work of the corresponding team > to see whether there is anything you are interested in: > https://salsa.debian.org/bazel-team/bazel > > On Wed, 2022-06-08 at 17:18 +0200, David Given wrote: > > I'm looking into converting some of my upstream packages to use Google's > bazel build system, because it makes life > > much easier as a developer. > > > > Unfortunately, with my other hat on, it makes life much harder as a > package maintainer: bazel is very keen on > > downloading source packages and then building them locally, resulting in > a mostly-statically-linked executable. > > protobuf is the most obvious culprit here, because if you do anything > with Google's ecosystem you inevitably end up > > using protobufs, and as soon as you refer to a cc_proto_library rule in > bazel you get a statically linked libprotobuf. > > > > Are there any known best practices yet in Debian on how to persuade > bazel not to do this, and to use the system one > > instead? > > > >
