Bug#915721: transition: opencv

[Mo Zhou <lumin@debian.org>]

Hi release team,

Shall we proceed with the opencv transition? The opencv 3.2.0 in
unstable
is too ancient. The automatically generated ben file looks good:

https://release.debian.org/transitions/html/auto-opencv.html

I'm planning to remove the mipsel architecture since it suffers
a lot from OOM issue during compilation, so please ignore the FTBFS
on mipsel:
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental

AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due
to
API changes or header path change.
I have already filed FTBFS bugs against those correcponding packages
when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think
the result won't be different.

On 2019-01-14 15:44, Mo Zhou wrote:
> On Sun, Jan 13, 2019 at 08:06:57PM +0100, Emilio Pozuelo Monfort wrote:
>>
>> What is the status with the rdeps? I looked at two bugs and they worry me:
> 
> I haven't had enough time to test rdeps for another round. But I guess
> the situation would be similar to the first round.
> 
>> #915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling
>> ffmpeg support altogether.
>>
>> #915709 seems to point to the same brokenness.
> 
> Quoted from upstream:
> https://github.com/opencv/opencv/issues/10963#issuecomment-369259044
> 
> | OpenCV 3.x doesn't not support C compilation mode officially.
> 
> And if you look at upstream Pull Requests you will find that upstream
> is gradually removing legacy C APIs.
> 
> So, those rdeps broken due to the C API are questionable because they
> are using non-officially supported (deprecated) part of opencv ...
> 
> There are another failing pattern, which stems from changes in C++ class
> method, and is easy to fix ...
> 
> I'm currently putting out the fire on the julia package so I cannot
> make a statistics.
> 
>> The way it looks, I don't think we can go ahead with this at this stage.
> 
> Both result are acceptable to me -- wether we can go ahead or not.
> Pausing the transition helps my laziness. Moving forward, although
> radical and breaks some questionable rdeps, brings some new features
> such as the DNN module which supports not only pre-trained tensorflow
> model.