Ghislain Vaillant <[email protected]> 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? >> I favor option 2. Any strong opinions either way? If I don't hear any >> complaining, I'll get the patches ready, and then talk about an actual >> upload. >> > 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. Let me see how simple the patch really would be.
