bazel-team team mailing list archive

[Julian Gilbey <jdg@xxxxxxxxxx>]

On Fri, Dec 25, 2020 at 10:48:11AM -0500, Olek Wojnar wrote:
> On Fri, Dec 25, 2020, 08:56 Julian Gilbey <jdg@xxxxxxxxxx> wrote:
> 
>   Hi Bazel team,
> 
> Hi Julian,
> 
>   A package I maintain (anki) has recently switched to using the Bazel
>   build system. 
> 
> Cool. It's a very nice build system.

Hi Olek,

That's good to hear!  I've been a rather overwhelmed with Real Life
and my day job recently, so this is all new to me :-)  I'm almost
certainly going to ask someone else to take over this package from me
as it's looking too nightmarish to manage in the little time I have
available for Debian maintenance :-(

>   I don't know yet how to modify their build process to
>   be able to build a Debian package, but before I get even that far, I
>   see that there is a bazel-bootstrap package in Debian but not a full
>   bazel package.
> 
>   Is there any intention to have one, or is the bootstrap version
>   enough?
> 
> We're working on getting the whole build system in Debian.[1] Unfortunately, I'm
> doing the majority of the packaging myself and life has been a little busy
> recently. :(

Amazing!  That's a lot of work, I'm guessing.  (And I really
understand life being busy!)

> There are 8 component packages that I still need to file RFP bugs for but at
> least five of them will be trivial to package. The actual bazel package will
> also be fairly simple once all 8 supporting components are packaged. I'm hopeful
> that I can get that all in before the freeze but we'll see.

Eeks!

>     I know almost nothing about bazel yet, but it would be useful
>   to know this before I get much deeper into things.
> 
> The bigger issue for Debian packaging is that Bazel upstream does not (yet) have
> a dynamic dependency resolution feature (i.e. we can't automatically direct
> Bazel to use Debian's version of libraries instead of downloading them from the
> Internet). 
> That's not a showstopper for Debian packaging, but it'll make it complicated
> until we get that feature implemented. If your package has relatively few
> dependencies, it may be reasonable to patch that behavior in. If anki is very
> complicated, that may be overwhelming. (I gave up on trying to do that with
> grpc-java, which is very complicated and has tons of dependencies) If you have a
> link to the Bazel packaging, I'm happy to take a look and give you my opinion.

Ooo, that will be an issue.  This package (upstream source at
https://github.com/dae/anki.git) now uses Python, Rust and Node
packages, so it's got quite a lot of dependencies.  I'm assuming it
calls cargo to build the Rust library, and goodness only knows what it
does with Node...  So this package may have to wait for buster+1,
which is fine - there's a perfectly good older version in buster.

Best wishes,

   Julian