Re: bazel-built binaries vs Debian packages
Yes, bazel brings many challenges in terms of packaging. I've gone
through a lot at the first attempts for tensorflow packaging, and
eventually realized that it works so differently by design in terms
of debian policy.
On Wed, 2022-08-03 at 15:55 +0100, Wookey wrote:
> On 2022-08-03 14:11 +0200, David Given wrote:
>
> > The problem is that bazel loves vendored source. ... It is
> > possible to force bazel to link against the system libraries but
> > this sort of thing is considered a bazel anti-pattern, it's hard,
> > and of course with my upstream hat on I don't want to do it as I
> > don't want to have to tailor my build system around Debian's
> > needs. So, what should I do? As bazel takeup increases I expect
> > this to be a growing problem, so it's not just me. Has anyone
> > thought of this?
>
> Yes. I've had this problem packaging tensorflow. I'm not upstream as
> well so I have no desire to do things the bazel way, but it is a big
> pain getting it to do things the distro (proper, reproducible) way.
>
> As you are upstream too my advice would be: use a better build system
> that isn't antithetical to proper distro packaging. There are plenty
> to choose from these days.
>
> I think the long-term solution to this is better bazel support for
> 'use system libraries'. It does have some but is currently arrange as
> a lot of work for each package/project. It should be possible to just
> turn on 'use system libraries' and have it use the right (much simpler
> as there is no downloading and tarball tagging and path-mangling
> involved) process, then mark anything which does need to be vendored
> as using the 'normal' bazel process.
>
> This involves some work in bazel from people like us who care about this.
>
> The alternative is just maintain a parallel build in a sensible build
> system (tensorflow now has a parallel cmake build which has largely
> solved my particular issues).
>
> So, yes there are other people affected/interested.
>
> Wookey
Reply to: