[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

  Files: all shlibs built against the default amd64 ISA

  Files: all shlibs built against avx2 baseline, installed into
         a specific path following ld.so's dispatching logic

  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

Comments and thoughts?

Reply to: