On Fri, Dec 08, 2017 at 01:57:26AM -0800, Dima Kogan wrote:
> Ghislain Vaillant <ghisvail@gmail.com> writes:
>
> >> 2. Patch our build of OpenCV3 that works with the older API. Right now,
> >> this actually is simple (I think). We'd just need to move the
> >> definition of cvRound() to C header instead of a C++ one. I'm sure
> >> there're details to be worked out, but it LOOKS easy. With time,
> >> these updates could become difficult, but not yet.
> > It might not stay that simple in the future.
> >
> > Again, that's part of evaluating the risks of taking on ourselves the
> > maintenance burden.
> >
> > Usually, if upstream does not care, I believe we should not either.
>
> Consumers of opencv-dev aren't just packages. Users build against this
> library directly, and this breakage is causing pain. I'm saying this as
> just such an annoyed user. I'm completely uninterested in a maintenance
> burden that's adversarial with upstream, but right now the broken thing
> should be easy to fix. Do you see downsides to keeping it working while
> it's still simple?
Yes, the downside is that currently the maintenance of OpenCV is already
under-optimal. I had to step up during the year to kick the 2.4.9 → 3.x
transition that had stalled for more than a year (that was making users
annoyed as well).
Adding a opencv2.4 package is completely out of discussion, I'm quite
sure nobody would be properly maintaining it.
I seriously doubt adding a patch like what you propose to the current
opencv packaging would be sustinable in the long run, and you'd find
yourself in the same position as now very soon when the patch doesn't
cleanly rebase anymore and it gets disabled.
> > If some legacy packages fail to keep up with the development of OpenCV,
> > then they should probably rely on a different distribution mechanism
> > than Debian. It's unfortunate upstream did not commit to keep a stable
> > C-API, but downstreams should also inform themselves and adapt as part
> > of their risk assessment.
>
> Yeah. Right. Thing is they didn't break the APIs. The biggest problem is
> that the C headers you're supposed to #include have some inlined
> functions that call stuff that now lives in a C++ header that only is
> included #ifdef __cplusplus.
Did anybody ever tried sending a PR upstream? In your first message you
linked to bug reports, not PRs.
I'd first start there, if such a patch is so simple as you claim it
would be, and it is techinically correct, I don't see a reason for it to
not be upstreamable.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature