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

Re: tensorflow_2.3.1-1_amd64.changes ACCEPTED into experimental, experimental

On Wed, 2022-02-09 at 19:53 +0000, Wookey wrote:
> My plan there was to move on to tensorflow 2.5.0 (or thereabouts)
> because cmake is allegedly properly supported and not having to deal
> with bazel and its perverse view of how things should be built would
> make things go so much faster.


> I don't know if there are issues with that. Certainly a newer
> tensorflow
> would presumably be a good thing?

Generally we should follow the new upstream releases. But we have
to also consider the bazel compactibility:

The master branch requires bazel 5.0.0 while we have 3.5.1 in unstable.

So it may be a good idea to upgrade to the latest tensorflow version
that the bazel in archive supports.

Version 2.5.3 requires 3.7.2 ... I don't know whether anything would

Bazel is volatile. When I worked on tensorflow packaging bazel
may break something on every version bump, in my impression.

> I guess if the 2.3.1 fix isn't too taxing people would like to have a
> working upload of that before version-bumping because then at least
> we
> have _something? Right. I do actually have a 2.3.1 with tflite built
> too (which was more-or-less working - there was some annoying issue
> with it insisting on downloading something or other IIRC). But of
> course even that would be another trip through new.
> So I guess I'm taking feedback on the relative usefulness of
> 1) a 2.3.1 that actually builds
> 2) a 2.3.1 with tflite too
> 3) a newer tensorflow version.
> Wookey

If you have tensorflow reverse dependencies in mind, or regard
tflite as an important component, please follow your mind.
I think fixing stuff in any order should be fine before
we ship the python3-tensorflow binary package.
Thus I hold a neutral view on the three options.

Reply to: