Bug#915721: transition: opencv

[Mo Zhou <lumin@debian.org>]

ping?

On 2019-09-30 09:02, Mo Zhou wrote:
> 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.