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 <
[email protected]> 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?
<div dir="ltr">They seem to be mostly interested in packaging bazel <i>for</i> Debian, while I'm more interested in building packages <i>with</i> 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...<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Jun 2022 at 00:38, M. Zhou <<a href="mailto:
[email protected]"
[email protected]</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David,<br>
Debian has a group of people working on bazel packaging.<br>
<a href="
https://lists.debian.org/debian-bazel/2022/06/threads.html" rel="noreferrer" target="_blank">
https://lists.debian.org/debian-bazel/2022/06/threads.html</a><br>
And bazel itself has been a years-long pain for tensorflow packaging.<br>
I'm not following the updates for bazel packaging, but you<br>
may browse the packaging work of the corresponding team<br>
to see whether there is anything you are interested in:<br>
<a href="
https://salsa.debian.org/bazel-team/bazel" rel="noreferrer" target="_blank">
https://salsa.debian.org/bazel-team/bazel</a><br>
On Wed, 2022-06-08 at 17:18 +0200, David Given wrote:<br>
> I'm looking into converting some of my upstream packages to use Google's bazel build system, because it makes life<br>
> much easier as a developer.<br>
> <br>
> Unfortunately, with my other hat on, it makes life much harder as a package maintainer: bazel is very keen on<br>
> downloading source packages and then building them locally, resulting in a mostly-statically-linked executable.<br>
> protobuf is the most obvious culprit here, because if you do anything with Google's ecosystem you inevitably end up<br>
> using protobufs, and as soon as you refer to a cc_proto_library rule in bazel you get a statically linked libprotobuf.<br>
> <br>
> Are there any known best practices yet in Debian on how to persuade bazel not to do this, and to use the system one<br>
> instead?<br>
> <br>
</blockquote></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)