Binary package organization of tensorflow and pytorch in the future
Hi team,
As discussed in another thread "Re: Recalling Key Points
of the Previous Attempt", the only way to provide AVX2-enabled
tensorflow from official Debian archive is to use the "hardware
capability" feature of ld.so.
To avoid bulky binary packages after we build multiple ISA versions
of libtensorflow*, we may have to split shared objects into separate
packages.
The current binary package layout is:
bin:libtensorflow-framework2 -> libtensorflow-framework.so.X
bin:libtensorflow2 -> libtensorflow.so.X
bin:libtensorflow-cc2 -> libtensorflow-cc.so.X
When we introduce packages such as
bin:libtensorflow-{framework,,cc}2-avx2 , the complexity increases.
More complexity will be added when we want to add the cuda/rocm/sycl
versions of tensorflow.
My preliminary proposal is to merge the libraries into one binary package,
e.g., the src:tensorflow packages produces the following binary packages:
bin:tensorflow (meta)
Depends: libtensorflow2, python3-tensorflow, libtensorflow-dev
bin:libtensorflow2 (meta)
Depends: libtensorflow2-generic | libtensorflow2-avx2 | libtensorflow2-avx512
Recommends: libtensorflow2-avx2, libtensorflow2-avx512
Comment: we want to install all variants by default to enable ld.so's
dispatching. But the meta package should be able to fulfill
with only one variant
bin:libtensorflow2-generic
Files: all shlibs built against the default amd64 ISA
bin:libtensorflow2-avx2
Files: all shlibs built against avx2 baseline, installed into
a specific path following ld.so's dispatching logic
bin:tensorflow-src
Files: all tensorflow sources
The last binary package bin:tensorflow-src is inspired by our GCC cross
compilation toolchain. We cannot build the cuda version of tensorflow
from the main section of our archive, of course. So we can introduce
another source package src:tensorflow-cuda (in the contrib section)
that Build-Depends: tensorflow-src so that we don't have to duplicate
a copy of code many times. src:tensorflow-rocm and src:tensorflow-sycl
can be created in similar ways.
As the current pytorch package maintainer, I think I'm going to change
the package organization in a similar way.
src:pytorch produces bin:libtorchX, bin:python3-torch, bin:pytorch-src, etc.
And src:pytorch-cuda, src:pytorch-rocm, src:pytorch-sycl can be dealt
with in an asynchronous way without blocking the progress on the cpu-only
version.
Comments and thoughts?
Reply to: