Description of problem:
In OpenCV 3.4.x (and earlier versions), the default name for the pkgconfig file was "opencv.pc"
OpenCV 4.x changed the default name of this file to "opencv4.pc"
However, when the package was updated to 4.x, presumably the build broke because the file was not being created with the name the spec file was expecting, and so the build config was changed to change the PC_FILE_NAME back to "opencv.pc": https://src.fedoraproject.org/rpms/opencv/c/a7f630433db89546a3920d05fb1a23ff0686c63e
This caused some issues for me building some software that expects "opencv4.pc" when building for OpenCV 4.0. Fedora is alone in doing this - both Debian and Arch are installing the upstream-default "opencv4.pc".
Unless there is a good reason otherwise, the name of this .pc file should probably not be overridden, and the spec file should install opencv4.pc instead.
This currently affects Fedora Rawhide and 32 Beta. Fedora 31 has 3.4.x, so it's fine.
I think the main issue is that opencv4 was (probably for very bad reason) meant to be parallele installable with opencv(3).
Can you state whitch package is affected by this ?
This is not un-usual thing to patch packages that make wrong assumption.
It should be possible for this change to be added upstream.
If you need opencv >= 4, you can use opencv.pc
pkgconf opencv --atleast-version 4.0 (or use the appropriate macro for this from your build system).
>Can you state whitch package is affected by this ?
Not an RPM package - I was building the Rust bindings for OpenCV. When building bindings for OpenCV 4, it expects "opencv4.pc" to exist. You can override this setting with an environment variable to make it build, so it's not a critical issue, but given that Fedora generally defers to upstream preferences moreso than Debian, it is surprising that Fedora is making a downstream modification where Debian and Arch are following the upstream approach.
Could you elaborate on what benefit is provided by changing the name downstream? I understand that Fedora itself doesn't gain benefit from parallel installation, but I don't see the benefit in overriding the default value either.
(In reply to Daniel Alley from comment #2)
> Could you elaborate on what benefit is provided by changing the name
> downstream? I understand that Fedora itself doesn't gain benefit from
> parallel installation, but I don't see the benefit in overriding the default
> value either.
Actually, I'm not changing the name, I more accurately keep the name from changing from opencv3 to opencv4 (even with a means that is offered in upstream opencv4).
There are lot of upstream projects using opencv.pc and I expect they are rights and accurate to do so. (specially given most compatibilty changes in opencv4 was actually changes made from opencv1 C API to opencv2 C++ API about 10 years ago).
By keeping the opencv.pc name, it allows many projects to use opencv4 unmodified.
We'll have to agree to disagree. Would you mind keeping the issue open for visibility?
Well, you can disagree, but I don't see much argument, so I don't see any reason to keep it open on the fedora side either.
I think the reporter have a point here, the issue is created by  , maybe we shouldn't change the OPENCV_PC_FILE_NAME, I don't remember why I did this ...
+ -DOPENCV_PC_FILE_NAME=opencv.pc \
Way too many opencv library users are using opencv.pc. That's the reason why it's kepted that way. There is no reason for such "interface break".
The one wanting to make the change back to opencv4.pc will also have to patch the many applications to make it build with opencv4.pc in a way that can be accepted by their upstream.
That's a lot of work and not something I'm going to do it for free.
and what about this idea ? make a symbol link opencv.pc -> opencv4.pc .
It will work in both cases.
Well, Agreed to have a symlink.
Fixed in f32+
FEDORA-2020-ece8d413ba has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ece8d413ba
FEDORA-2020-ece8d413ba has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ece8d413ba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ece8d413ba
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-ece8d413ba has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.