well, everything seems to link against openblas so getting that out might be hard, but vtk separates out easily. Only libopencv_viz is linked against it.

debian seems to give just about every library its own subpackage:

https://packages.debian.org/source/stable/opencv

other deps I noted:

* only libopencv_text uses libtesseract
* only libopencv_ccalib , libopencv_cvv and libopencv_highgui use Qt5

* only libopencv_videostab uses libClp and libCoinUtils

I saw your message on the mailing list and unfortunately, I don't get why gst plugin that uses opencv should be on the default fedora install in the first step ?
OpenCV has an outrageous mis-design WRT runtime dependencies: (as referenced in the spec: https://github.com/opencv/opencv/issues/7001), this is known.
On my side I've dropped opencv support for some "core" multimedia dependencies on 3rd part (ffmpeg) for this very much reason.

Whatever the dependency computation that can be made for a given opencv release, it will be trashed on the next update. So my advice is to drop the gst plugin using opencv as a sub-package and enforce it not into the default Fedora install set of packages.
Is that good for you ?

I mean, they're two different issues. We already changed the gstreamer plugins package, but plenty of other things use opencv and so its giant dep tree affect them.

I already suggested a pretty simple change here: just split each openxv lib into its own sub package, so other things that build against opencv only pull in the library sub package(s) and associated deps they actually need. If something only links against the core lib, for e.g., this would save it pulling in qt5 and java and vtk and all sorts of other things. Is there any reason we can't do that?

I don't know how many issues to count for this problem, but one other aspect of the same issue is that some opencv users links to all opencv core libraries no matter of which one they really use (mainly because they use the broken opencv.pc/cmake).

So splitting into sub-package without fixing theses will be pointless in theses cases.

Note that I'm open with improvement with further sub-packaging opencv libs.

I'm not yet sure to prefer sorting libs in sub-packages by dependencies cost over having a each single lib it own sub-package.

Well, I just did a quick dumb check on this. Here's the results:

PACKAGE REQUIRING LIBOPENCV_CORE        DOES IT REQUIRE ALL OPENCV LIBS?

OpenImageIO                             NO
YafaRay-lib                             NO
digikam-libs                            NO
frei0r-plugins-opencv                   NO
gmic                                    YES
libfreenect-opencv                      NO
lives                                   NO
nomacs                                  NO
nomacs-plugins                          NO
opencv                                  NO
opencv-contrib                          NO
opencv-devel                            YES
opencv-java                             NO
os-autoinst                             NO
performous                              NO
php-facedetect                          YES
player                                  NO
python3-opencv                          NO (most, but probably needs to)
qimgv                                   NO
simarrange                              YES
siril                                   NO
waifu2x-converter-cpp                   NO

so, there's four packages that could probably be improved, but the significant majority of packages that require opencv_core do not require all the other libs too (they mostly require only 2-4 of them).

this commit [1] should change a lot of dependencies because many modules change from core to contrib and vice-versa 


[1]
https://src.fedoraproject.org/rpms/opencv/c/0a5887a0d1dd62efec577ab7daa161e525ea5af2?branch=rawhide

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I re-ran the mock test on current Rawhide. Installing opencv-core on top of a clean Rawhide mock root pulls in:

CharLS
SuperLU
alsa-lib
armadillo
arpack
avahi-libs
cairo
cdparanoia-libs
cfitsio
cmake-filesystem
crypto-policies-scripts
cups-libs
dbus-libs
dejavu-sans-fonts
expat
flexiblas
flexiblas-netlib
flexiblas-netlib64
flexiblas-openblas-openmp
flexiblas-openblas-openmp64
fontconfig
fonts-filesystem
freetype
freexl
fribidi
gdal-libs
gdcm
geos
giflib
glib2
glx-utils
gnutls
graphene
graphite2
gstreamer1
gstreamer1-plugins-base
harfbuzz
hdf-libs
hdf5
hwdata
imath
intel-mediasdk
iso-codes
jasper-libs
jbigkit-libs
json-c
langpacks-core-font-en
lcms2
libICE
libSM
libX11
libX11-common
libX11-xcb
libXau
libXext
libXfixes
libXft
libXrender
libXv
libXxf86vm
libaec
libdap
libdatrie
libdc1394
libdrm
libevdev
libevent
libgeotiff
libgfortran
libglvnd
libglvnd-egl
libglvnd-glx
libglvnd-opengl
libgta
libgudev
libicu
libinput
libjpeg-turbo
libkml
libogg
libpciaccess
libpng
libpq
libquadmath
libraw1394
librttopo
libspatialite
libthai
libtheora
libtiff
libtool-ltdl
libunwind
libusb1
libva
libvisual
libvorbis
libwacom
libwacom-data
libwayland-client
libwayland-cursor
libwayland-egl
libwayland-server
libwebp
libxcb
libxkbcommon
libxkbcommon-x11
libxshmfence
mariadb-connector-c
mariadb-connector-c-config
mesa-filesystem
mesa-libEGL
mesa-libGL
mesa-libgbm
mesa-libglapi
minizip
mpdecimal
mtdev
netcdf
nettle
nspr
nss
nss-softokn
nss-softokn-freebl
nss-sysinit
nss-util
ogdi
openblas
openblas-openmp
openblas-openmp64
openblas-serial
openexr-libs
openjpeg2
opus
orc
pango
pcre2-utf16
pixman
poppler
poppler-data
proj
protobuf
python-pip-wheel
python-setuptools-wheel
python3
python3-libs
qt-settings
qt5-qtbase
qt5-qtbase-common
qt5-qtbase-gui
tbb
unixODBC
uriparser
xcb-util
xcb-util-image
xcb-util-keysyms
xcb-util-renderutil
xcb-util-wm
xerces-c
xkeyboard-config
xml-common

It's a bit better than before - 160 things vs. 214 before. But it still seems pretty long and includes a lot of stuff that could be avoided by subpackaging the libs.

comparing from first list to second we see that have lot of removes  


@@ -2,25 +2,16 @@ alsa-lib
armadillo
arpack
avahi-libs
-byte-buddy
-byte-buddy-agent
cairo
cdparanoia-libs
cfitsio
CharLS
-cliquer-libs
cmake-filesystem
-coin-or-Cbc
-coin-or-Cgl
-coin-or-Clp
-coin-or-CoinUtils
-coin-or-Osi
-copy-jdk-configs
crypto-policies-scripts
cups-libs
dbus-libs
dejavu-sans-fonts
-double-conversion
+expat
flexiblas
flexiblas-netlib
flexiblas-netlib64
@@ -32,52 +23,37 @@ freetype
freexl
fribidi
gdal-libs
-gdbm-libs
gdcm
-gecode
geos
giflib
glib2
-glpk
glx-utils
gnutls
graphene
graphite2
-gsl
gstreamer1
gstreamer1-plugins-base
harfbuzz
-hawtjni-runtime
hdf5
hdf-libs
hwdata
-ilmbase
+imath
+intel-mediasdk
iso-codes
-jacop
-jansi
-jansi-native
jasper-libs
-java-11-openjdk-headless
-javapackages-filesystem
-javapackages-tools
jbigkit-libs
-jline
json-c
-jsoncpp
langpacks-core-font-en
lcms2
-leptonica
libaec
libdap
libdatrie
libdc1394
libdrm
-libedit
libevdev
libevent
libgeotiff
libgfortran
-libGLEW
libglvnd
libglvnd-egl
libglvnd-glx
@@ -89,20 +65,21 @@ libicu
libinput
libjpeg-turbo
libkml
-libnauty
libogg
libpciaccess
libpng
libpq
libquadmath
libraw1394
+librttopo
libSM
libspatialite
libthai
libtheora
libtiff
+libtool-ltdl
libunwind
-libusbx
+libusb1
libva
libvisual
libvorbis
@@ -118,7 +95,6 @@ libX11-common
libX11-xcb
libXau
libxcb
-libXdamage
libXext
libXfixes
libXft
@@ -126,18 +102,8 @@ libxkbcommon
libxkbcommon-x11
libXrender
libxshmfence
-libXt
libXv
libXxf86vm
-lksctp-tools
-llvm-libs
-Lmod
-lua
-lua-filesystem
-lua-json
-lua-lpeg
-lua-posix
-lua-term
mariadb-connector-c
mariadb-connector-c-config
mesa-filesystem
@@ -145,13 +111,9 @@ mesa-libEGL
mesa-libgbm
mesa-libGL
mesa-libglapi
-mesa-libOSMesa
-metis
-mockito
-mp
+minizip
+mpdecimal
mtdev
-MUMPS
-MUMPS-common
netcdf
nettle
nspr
@@ -160,17 +122,13 @@ nss-softokn
nss-softokn-freebl
nss-sysinit
nss-util
-objectweb-asm
-objenesis
ogdi
openblas
openblas-openmp
openblas-openmp64
openblas-serial
-opencv-contrib
-OpenEXR-libs
+openexr-libs
openjpeg2
-opentest4j
opus
orc
pango
@@ -178,11 +136,8 @@ pcre2-utf16
pixman
poppler
poppler-data
-procps-ng
proj
-proj-datumgrid
protobuf
-pugixml
python3
python3-libs
python-pip-wheel
@@ -191,19 +146,10 @@ qt5-qtbase
qt5-qtbase-common
qt5-qtbase-gui
qt-settings
-scala
-scotch
-suitesparse
SuperLU
tbb
-tcl
-tesseract
-tesseract-langpack-eng
-tesseract-tessdata-doc
-tzdata-java
unixODBC
uriparser
-vtk
xcb-util
xcb-util-image

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

A (hopefully) thorough analysis of OpenCV component usage can be found here:

https://docs.google.com/spreadsheets/d/1q1rZpo-jeXddLKU3UCxulfyOEHumdU5RYo336Fld1VE/edit#gid=0

Points worth noting:

* -Wl,--as-needed in the default build flags prevents most overlinking nowadays, but php-facedetect and simarrange are clearly overlinked at present.  PRs have been filed for both.

* core and imgproc are the only components used (almost) universally.

* gapi and stitching from "core" are not used, but don't really add any dependencies.

* highgui and ccalib from "core" and cvv from "contrib" depend on Qt, and only highgui is used and even then not by much.

* Only two "contrib" components are/will be used by other packages (so far): bgsegm and tracking, neither of which have non-core dependencies.

* Most of the dependencies in "core" come from:
- imgcodecs: gdal(*), gdcm, openexr, openjpeg, libpng, libtiff, libwebp
- videoio: gstreamer1*, libdc1394, libmfx, libva

* "contrib" components with non-core dependencies are:
- freetype: harfbuzz
- hdf: hdf5
- text: tesseract
- videostab: coin-or-*
- viz: vtk

Created attachment 1987651 [details]
NEEDED dependencies of each library component

After filling in transitive dependencies in that chart, one more "contrib" is used (xobjdetect, by the utilities).  Also, it has become apparent that most of "core" -- except for ccalib and highgui with their Qt dependencies -- are often used in tandem, either directly or indirectly.

A few possible ways to better manage these dependencies:

1) "Promote" bgsegm, tracking, and xobjdetect to "core", split out highgui and ccalib into a separate subpackage, and leave everything unused in "contrib".

2) Completely redivide the components based on their use and dependencies, e.g.:
   "core": core, dnn, features2d, flann, imgproc, ml, photo, and maybe stitching
   "base": calib3d, imgcodecs, objdetect, video, videoio, bgsegm, tracking, xobjdetect, and maybe gapi
   "gui": highgui, and maybe ccalib and/or cvv
   "extras": everything else (should be unused aside from opencv-devel, python3-opencv, and opencv-java)
This would minimize the dependencies of YafaRay, nomacs, and qimgv which would only use "core", libfreenect-opencv which would use only "core" and "gui", and the vast majority of consumers would *not* pull in Qt where they don't need it (or not the same version as OpenCV).

3) Create subpackages for each component (or at least each "core" or used "contrib") and each unused component with notable additional dependencies (e.g. text, videostab, viz), and leave the rest unused compontents without notable additional dependencies in "contrib".

I still need to check if python3-opencv and opencv-java, which currently show dependencies on almost all components, aren't themselves overlinked.

Any feedback on these proposals?  I'd like to get this fixed one way or the other for building in F39 flatpaks.

I kinda like the idea of 3), but not sure how much work it would be. Thanks for looking into this!

From my understanding of your sketch, core and imgproc are used everywhere.
Problem is that core and imgproc already comes with a load of non-trivial dependencies (X, GL, blas, tbb). So at this point adding another opencv library that won't add much dependency won't be an issue.

What I find limiting is that you sorted opencv libs alphabetically instead of splitting on either they comes from core or contrib source archive.
Also finding third part library might weigh in the computation... Specially as your interest is to get rid of qt deps.

(In reply to Nicolas Chauvet (kwizart) from comment #22)
> From my understanding of your sketch, core and imgproc are used everywhere.

Correct.

> Problem is that core and imgproc already comes with a load of non-trivial
> dependencies (X, GL, blas, tbb). 

It isn't that many really:

$ ldd /usr/lib64/libopencv_core.so.407 
	linux-vdso.so.1 (0x00007ffd277f6000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fefcf558000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fefcf525000)
	libopenblas.so.0 => /lib64/libopenblas.so.0 (0x00007fefcd108000)
	libtbb.so.2 => /lib64/libtbb.so.2 (0x00007fefcd0c4000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fefcce70000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fefccd8f000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fefccd6b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fefccb8d000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007fefcca46000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007fefcca32000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fefcc97a000)
	libgfortran.so.5 => /lib64/libgfortran.so.5 (0x00007fefcc6a5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fefcf942000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fefcc678000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007fefcc672000)

> So at this point adding another opencv
> library that won't add much dependency won't be an issue.

core's dependencies are nothing compared to imgcodecs, which is why I'm proposing some form of separation between them:

$ ldd /usr/lib64/libopencv_imgcodecs.so.407 
	linux-vdso.so.1 (0x00007ffe8dddf000)
	libopencv_imgproc.so.407 => /lib64/libopencv_imgproc.so.407 (0x00007f4d21bdd000)
	libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f4d21b5a000)
	libwebp.so.7 => /lib64/libwebp.so.7 (0x00007f4d21aec000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f4d21ab3000)
	libgdcmMSFF.so.3.0 => /lib64/libgdcmMSFF.so.3.0 (0x00007f4d21935000)
	libtiff.so.5 => /lib64/libtiff.so.5 (0x00007f4d218ac000)
	libopenjp2.so.7 => /lib64/libopenjp2.so.7 (0x00007f4d2184a000)
	libOpenEXR-3_1.so.30 => /lib64/libOpenEXR-3_1.so.30 (0x00007f4d21531000)
	libgdal.so.32 => /lib64/libgdal.so.32 (0x00007f4d1fea7000)
	libopencv_core.so.407 => /lib64/libopencv_core.so.407 (0x00007f4d1faed000)
	libgdcmDSED.so.3.0 => /lib64/libgdcmDSED.so.3.0 (0x00007f4d1fa5d000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f4d1f97c000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4d1f726000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4d1f702000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4d1f524000)
	libsharpyuv.so.0 => /lib64/libsharpyuv.so.0 (0x00007f4d1f51c000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f4d1f502000)
	libgdcmDICT.so.3.0 => /lib64/libgdcmDICT.so.3.0 (0x00007f4d1f22c000)
	libgdcmjpeg8.so.3.0 => /lib64/libgdcmjpeg8.so.3.0 (0x00007f4d1f1fe000)
	libgdcmjpeg12.so.3.0 => /lib64/libgdcmjpeg12.so.3.0 (0x00007f4d1f1d2000)
	libgdcmjpeg16.so.3.0 => /lib64/libgdcmjpeg16.so.3.0 (0x00007f4d1f1a6000)
	libCharLS.so.2 => /lib64/libCharLS.so.2 (0x00007f4d1f148000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4d1f13e000)
	libjson-c.so.5 => /lib64/libjson-c.so.5 (0x00007f4d1f12a000)
	libgdcmIOD.so.3.0 => /lib64/libgdcmIOD.so.3.0 (0x00007f4d1f118000)
	libgdcmCommon.so.3.0 => /lib64/libgdcmCommon.so.3.0 (0x00007f4d1f0de000)
	libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f4d1f022000)
	libLerc.so.4 => /lib64/libLerc.so.4 (0x00007f4d1ef95000)
	libjbig.so.2.1 => /lib64/libjbig.so.2.1 (0x00007f4d1ef87000)
	libImath-3_1.so.29 => /lib64/libImath-3_1.so.29 (0x00007f4d1ef37000)
	libIlmThread-3_1.so.30 => /lib64/libIlmThread-3_1.so.30 (0x00007f4d1ef2b000)
	libIex-3_1.so.30 => /lib64/libIex-3_1.so.30 (0x00007f4d1eea1000)
	libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f4d1edf3000)
	libodbc.so.2 => /lib64/libodbc.so.2 (0x00007f4d1ed82000)
	libodbcinst.so.2 => /lib64/libodbcinst.so.2 (0x00007f4d1ed6e000)
	libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f4d1ebf8000)
	libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f4d1e7d1000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f4d1e79e000)
	libarmadillo.so.10 => /lib64/libarmadillo.so.10 (0x00007f4d1e788000)
	libqhull_r.so.7 => /lib64/libqhull_r.so.7 (0x00007f4d1e729000)
	libxerces-c-3.2.so => /lib64/libxerces-c-3.2.so (0x00007f4d1e3a3000)
	libgeotiff.so.5 => /lib64/libgeotiff.so.5 (0x00007f4d1e36b000)
	libpoppler.so.126 => /lib64/libpoppler.so.126 (0x00007f4d1df9d000)
	libgif.so.7 => /lib64/libgif.so.7 (0x00007f4d1df90000)
	libnetcdf.so.19 => /lib64/libnetcdf.so.19 (0x00007f4d1dd82000)
	libcfitsio.so.10 => /lib64/libcfitsio.so.10 (0x00007f4d1da6a000)
	libhdf5.so.200 => /lib64/libhdf5.so.200 (0x00007f4d1d69b000)
	libgta.so.1 => /lib64/libgta.so.1 (0x00007f4d1d68e000)
	libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f4d1d540000)
	libpq.so.5 => /lib64/libpq.so.5 (0x00007f4d1d4eb000)
	libkmlbase.so.1 => /lib64/libkmlbase.so.1 (0x00007f4d1d4c8000)
	libkmldom.so.1 => /lib64/libkmldom.so.1 (0x00007f4d1d428000)
	libkmlengine.so.1 => /lib64/libkmlengine.so.1 (0x00007f4d1d3f6000)
	libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f4d1d35a000)
	libspatialite.so.7 => /lib64/libspatialite.so.7 (0x00007f4d1cc3e000)
	libmariadb.so.3 => /lib64/libmariadb.so.3 (0x00007f4d1cbe3000)
	libfreexl.so.1 => /lib64/libfreexl.so.1 (0x00007f4d1cbd7000)
	libogdi.so.4 => /lib64/libogdi.so.4 (0x00007f4d1cbba000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f4d1cb8f000)
	libgeos_c.so.1 => /lib64/libgeos_c.so.1 (0x00007f4d1cb48000)
	libproj.so.25 => /lib64/libproj.so.25 (0x00007f4d1c786000)
	libdf.so.0 => /lib64/libdf.so.0 (0x00007f4d1c6d9000)
	libmfhdf.so.0 => /lib64/libmfhdf.so.0 (0x00007f4d1c6ae000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4d221e8000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f4d1c67b000)
	libopenblas.so.0 => /lib64/libopenblas.so.0 (0x00007f4d1a258000)
	libtbb.so.2 => /lib64/libtbb.so.2 (0x00007f4d1a214000)
	libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f4d1a1e9000)
	libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f4d1a19c000)
	libssh.so.4 => /lib64/libssh.so.4 (0x00007f4d1a12b000)
	libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f4d1a116000)
	libssl.so.3 => /lib64/libssl.so.3 (0x00007f4d1a073000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f4d1a01d000)
	libldap.so.2 => /lib64/libldap.so.2 (0x00007f4d19fb8000)
	liblber.so.2 => /lib64/liblber.so.2 (0x00007f4d19fa6000)
	libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f4d19f99000)
	libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f4d19f8e000)
	libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x00007f4d19c26000)
	libarpack.so.2 => /lib64/libarpack.so.2 (0x00007f4d19bdc000)
	libsuperlu.so.5 => /lib64/libsuperlu.so.5 (0x00007f4d19b68000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f4d19a98000)
	libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f4d19a49000)
	liblcms2.so.2 => /lib64/liblcms2.so.2 (0x00007f4d199e4000)
	libsmime3.so => /lib64/libsmime3.so (0x00007f4d199b9000)
	libnss3.so => /lib64/libnss3.so (0x00007f4d1987f000)
	libplc4.so => /lib64/libplc4.so (0x00007f4d19878000)
	libnspr4.so => /lib64/libnspr4.so (0x00007f4d19832000)
	libhdf5_hl.so.200 => /lib64/libhdf5_hl.so.200 (0x00007f4d1980e000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f4d197fa000)
	libsz.so.2 => /lib64/libsz.so.2 (0x00007f4d197f0000)
	liburiparser.so.1 => /lib64/liburiparser.so.1 (0x00007f4d197d7000)
	libminizip.so.3 => /lib64/libminizip.so.3 (0x00007f4d197ae000)
	librttopo.so.1 => /lib64/librttopo.so.1 (0x00007f4d19735000)
	libtirpc.so.3 => /lib64/libtirpc.so.3 (0x00007f4d19705000)
	libgeos.so.3.11.1 => /lib64/libgeos.so.3.11.1 (0x00007f4d194ad000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f4d19366000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f4d19350000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f4d19298000)
	libgfortran.so.5 => /lib64/libgfortran.so.5 (0x00007f4d18fc3000)
	libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f4d18e15000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f4d18d3c000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4d18d22000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f4d18d1b000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f4d18d0b000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f4d18d04000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4d18cf2000)
	libevent-2.1.so.7 => /lib64/libevent-2.1.so.7 (0x00007f4d18c9a000)
	libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f4d18c79000)
	libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f4d18c56000)
	libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007f4d18c0e000)
	libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f4d18b12000)
	libnssutil3.so => /lib64/libnssutil3.so (0x00007f4d18adf000)
	libplds4.so => /lib64/libplds4.so (0x00007f4d18ad8000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f4d18aad000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4d18a80000)
	libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f4d18a47000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f4d188fc000)
	libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f4d188db000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f4d188d5000)

> What I find limiting is that you sorted opencv libs alphabetically instead
> of splitting on either they comes from core or contrib source archive.

Columns B through P are components from core sources, column Q is empty as a delineater, and columns R through BE are components from contrib sources (with those having actual dependents listed first).  Same in the other direction, rows 28-42 are core, 43 blank, and 44 onward contrib (which I only highlighted some, as most are unused).

> Also finding third part library might weigh in the computation... Specially
> as your interest is to get rid of qt deps.

I wasn't sure how to represent that in the same sheet, but there are comments for notable cases.  To summarize though:

- dnn: protobuf
- highgui/ccalib/cvv: qt5-qtbase-gui (and all its deps)
- gapi: gstreamer1*
- imgcodecs: gdal (which itself has many deps), gdcm, openexr, openjpeg, libpng, libtiff, libwebp
- videoio: gstreamer1*, libdc1394, libmfx, libva
- text: tesseract
- videostab: coin-or-Clp (and its many deps)
- viz: vtk

Which given the various interdependencies, depending on how much you want to preserve the core/contrib source divide, it would require division into at least the following groupings:

 group 1 ("core"): core, dnn, features2d, flann, imgproc, ml, photo
 group 2 ("video"?): calib3d, gapi, imgcodecs, objdetect, stitching, video, videoio (and maybe bgsegm, tracking, xobjdetect from contrib)
 group 3 ("highgui"): highgui (and maybe ccalib and cvv from contrib)
 group 4 ("text"): text
 group 5 ("videostab"): videostab
 group 6 ("viz"): viz
 group 7 ("contrib-gui"): ccalib, cvv (if not included in "highgui")
 group 8 ("contrib"): all remaining contrib not mentioned above

(Any discrepencies between this and earlier comments are due to further refinements in this analysis and proposal.)

This kinda complexity in doing a 'bespoke' division is why I like the idea of just having a package per component. That's nice and clear and straightforward. We'd have to update all the dependencies, but it would make things clearest, I think.

(In reply to Adam Williamson from comment #24)
> This kinda complexity in doing a 'bespoke' division is why I like the idea
> of just having a package per component. That's nice and clear and
> straightforward.

There are complications and tradeoffs either way.  There are ~55 modules packaged in the latest version, which is a lot for a package this size, and there would probably have to be a macro for creating per-module subpackages to make it manageable.  Also, you wouldn't gain much fidelity in terms of dependencies given the interdependencies between modules, and remember that -devel will ultimately require every single one.

To be clear, I'm not particularly advocating for one method over the other.  Since this isn't my package, my default mode is to make/suggest the most minimal changes necessary to achieve the objective (in this case, the ~8 groups described above), but that doesn't mean "going further" is wrong either.  Ultimately, we need input from the package maintainers as to what they would prefer, and then we can work towards an implementation.

> We'd have to update all the dependencies, but it would make
> things clearest, I think.

Sorry, not quite sure what you mean by this.  Dependent packages should be referring to components by SONAME, so aside from needing Obsoletes:opencv-contrib the upgrade "should be" straight-forward (yeah, I know...).

@yaakov
I didn't have much time theses day and still running low. I've read again some part of the previous message that I've missed.

With this analysis, I'm less reluctant to use a package per component as it seems like a simplification and non-arbitrary split of components, agreed with Adam.
Only point is that at least for f39, this looks short to implement and fine-tune the rights RPM macros to handle this sanely...

@yaakov 
I'd like see the results, you can build the package on copr ? 

if you ask me permissions here [1] you can build it in my copr repo 

[1] 
https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/permissions/

(In reply to Sergio Basto from comment #27)
> I'd like see the results, you can build the package on copr ? 
> if you ask me permissions here [1] you can build it in my copr repo 

Requested.  In the meantime, I have updated https://src.fedoraproject.org/rpms/opencv/pull-request/24 which will trigger a CI scratch build.

[1] I don't know , seems to much sub-packages, to me , but if reflects the  opencv moudles that is listed in build logs [2] 

[2]
OpenCV modules:

--     To be built:                 alphamat aruco bgsegm bioinspired calib3d ccalib core cvv datasets dnn dnn_objdetect dnn_superres dpm face features2d flann freetype fuzzy gapi hdf hfs highgui img_hash imgcodecs imgproc intensity_transform java line_descriptor mcc ml objdetect optflow phase_unwrapping photo plot python3 quality rapid reg rgbd saliency shape stereo stitching structured_light superres surface_matching text tracking ts video videoio videostab viz wechat_qrcode ximgproc xobjdetect xphoto

[1] 
Built Packages:
    opencv-intensity_transform 4.8.0
    opencv-rapid 4.8.0
    opencv-viz-debuginfo 4.8.0
    opencv-aruco 4.8.0
    opencv-plot 4.8.0
    opencv-dnn 4.8.0
    opencv-structured_light 4.8.0
    opencv-dnn_superres 4.8.0
    opencv-java 4.8.0
    opencv-video-debuginfo 4.8.0
    opencv-objdetect 4.8.0
    opencv-alphamat 4.8.0
    opencv-saliency 4.8.0
    opencv-flann 4.8.0
    opencv-hfs 4.8.0
    opencv-video 4.8.0
    opencv-imgcodecs 4.8.0
    opencv-imgproc 4.8.0
    opencv-line_descriptor 4.8.0
    opencv-videostab 4.8.0
    opencv-reg 4.8.0
    opencv-core 4.8.0
    opencv-fuzzy 4.8.0
    opencv-phase_unwrapping 4.8.0
    opencv-stitching 4.8.0
    opencv-text 4.8.0
    opencv-quality 4.8.0
    opencv-rgbd 4.8.0
    opencv-xphoto 4.8.0
    opencv-viz 4.8.0
    opencv-wechat_qrcode 4.8.0
    opencv-bioinspired 4.8.0
    opencv-mcc 4.8.0
    opencv-superres 4.8.0
    opencv-xobjdetect 4.8.0
    opencv-dpm-debuginfo 4.8.0
    opencv-debuginfo 4.8.0
    opencv-plot-debuginfo 4.8.0
    opencv-devel 4.8.0
    opencv-freetype 4.8.0
    opencv-optflow 4.8.0
    opencv-bgsegm 4.8.0
    opencv-gapi 4.8.0
    opencv-stereo 4.8.0
    opencv-shape 4.8.0
    opencv-doc 4.8.0
    opencv-img_hash 4.8.0
    opencv-calib3d 4.8.0
    python3-opencv 4.8.0
    opencv-cvv 4.8.0
    opencv-datasets 4.8.0
    opencv-dnn_objdetect 4.8.0
    opencv-tracking 4.8.0
    opencv-ximgproc 4.8.0
    opencv-videoio 4.8.0
    opencv-surface_matching 4.8.0
    opencv-face 4.8.0
    opencv-ccalib 4.8.0
    opencv-dpm 4.8.0
    opencv-highgui 4.8.0
    opencv-ml 4.8.0
    opencv-photo 4.8.0
    opencv-hdf 4.8.0
    opencv-data 4.8.0
    opencv 4.8.0
    opencv-features2d 4.8.0

(In reply to Sergio Basto from comment #29)
> [1] I don't know , seems to much sub-packages, to me , but if reflects the 
> opencv moudles that is listed in build logs [2] 

Indeed it is a lot of subpackages, but that's what Nicolas and Adam requested.  Now that you've seen the results, how do you want to move forward?

I'd say "suggested", not "requested" :D It's not my package.

On my side, I admin I won't be able to do any work until the end of the next month. (past f39 GA).

So I might need to defer the one library split to rawhide instead . The main issue is that the opencv-devel packages doesn't requires all sub-packaged libraries now.

It might be wise to pick your previous attempt that split the qt5 libraries instead for f39

(In reply to Nicolas Chauvet (kwizart) from comment #32)
> On my side, I admin I won't be able to do any work until the end of the next
> month. (past f39 GA).

It would be helpful to get this into F39, so please let me know what more I can do.

> So I might need to defer the one library split to rawhide instead . The main
> issue is that the opencv-devel packages doesn't requires all sub-packaged
> libraries now.

Not in the explicit form `Requires: %{name}-%{component} = %{version}-%{release}`, but there are automatic dependencies:

Processing files: opencv-devel-4.8.0-2.fc40.x86_64
Provides: cmake(OpenCV) cmake(opencv) opencv-devel = 4.8.0-2.fc40 opencv-devel(x86-64) = 4.8.0-2.fc40 pkgconfig(opencv) = 4.8.0 pkgconfig(opencv4) = 4.8.0
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /usr/bin/pkg-config cmake-filesystem(x86-64) libopencv_alphamat.so.408()(64bit) libopencv_aruco.so.408()(64bit) libopencv_bgsegm.so.408()(64bit) libopencv_bioinspired.so.408()(64bit) libopencv_calib3d.so.408()(64bit) libopencv_ccalib.so.408()(64bit) libopencv_core.so.408()(64bit) libopencv_cvv.so.408()(64bit) libopencv_datasets.so.408()(64bit) libopencv_dnn.so.408()(64bit) libopencv_dnn_objdetect.so.408()(64bit) libopencv_dnn_superres.so.408()(64bit) libopencv_dpm.so.408()(64bit) libopencv_face.so.408()(64bit) libopencv_features2d.so.408()(64bit) libopencv_flann.so.408()(64bit) libopencv_freetype.so.408()(64bit) libopencv_fuzzy.so.408()(64bit) libopencv_gapi.so.408()(64bit) libopencv_hdf.so.408()(64bit) libopencv_hfs.so.408()(64bit) libopencv_highgui.so.408()(64bit) libopencv_img_hash.so.408()(64bit) libopencv_imgcodecs.so.408()(64bit) libopencv_imgproc.so.408()(64bit) libopencv_intensity_transform.so.408()(64bit) libopencv_line_descriptor.so.408()(64bit) libopencv_mcc.so.408()(64bit) libopencv_ml.so.408()(64bit) libopencv_objdetect.so.408()(64bit) libopencv_optflow.so.408()(64bit) libopencv_phase_unwrapping.so.408()(64bit) libopencv_photo.so.408()(64bit) libopencv_plot.so.408()(64bit) libopencv_quality.so.408()(64bit) libopencv_rapid.so.408()(64bit) libopencv_reg.so.408()(64bit) libopencv_rgbd.so.408()(64bit) libopencv_saliency.so.408()(64bit) libopencv_shape.so.408()(64bit) libopencv_stereo.so.408()(64bit) libopencv_stitching.so.408()(64bit) libopencv_structured_light.so.408()(64bit) libopencv_superres.so.408()(64bit) libopencv_surface_matching.so.408()(64bit) libopencv_text.so.408()(64bit) libopencv_tracking.so.408()(64bit) libopencv_video.so.408()(64bit) libopencv_videoio.so.408()(64bit) libopencv_videostab.so.408()(64bit) libopencv_viz.so.408()(64bit) libopencv_wechat_qrcode.so.408()(64bit) libopencv_ximgproc.so.408()(64bit) libopencv_xobjdetect.so.408()(64bit) libopencv_xphoto.so.408()(64bit)

I would have to see if there is a way of improving the macro to allow for explicit Requires of -devel.  Otherwise I could add the list manually but that seems ugly.

> It might be wise to pick your previous attempt that split the qt5 libraries
> instead for f39

Is the -devel requires your only issue?

Added opencv_devel_requires to the PR.  CI scratch build is in progress, and rpmspec -P shows:

```
%package        devel
Summary:        Development files for using the OpenCV library
Requires:       opencv(x86-64) = 4.8.0-2.fc38
Requires:       opencv-data(x86-64) = 4.8.0-2.fc38
Requires:       opencv-core(x86-64) = 4.8.0-2.fc38 opencv-calib3d(x86-64) = 4.8.0-2.fc38 opencv-dnn(x86-64) = 4.8.0-2.fc38 opencv-features2d(x86-64) = 4.8.0-2.fc38 opencv-flann(x86-64) = 4.8.0-2.fc38 opencv-gapi(x86-64) = 4.8.0-2.fc38 opencv-highgui(x86-64) = 4.8.0-2.fc38 opencv-imgcodecs(x86-64) = 4.8.0-2.fc38 opencv-imgproc(x86-64) = 4.8.0-2.fc38 opencv-ml(x86-64) = 4.8.0-2.fc38 opencv-objdetect(x86-64) = 4.8.0-2.fc38 opencv-photo(x86-64) = 4.8.0-2.fc38 opencv-stitching(x86-64) = 4.8.0-2.fc38 opencv-video(x86-64) = 4.8.0-2.fc38 opencv-videoio(x86-64) = 4.8.0-2.fc38 opencv-alphamat(x86-64) = 4.8.0-2.fc38 opencv-aruco(x86-64) = 4.8.0-2.fc38 opencv-bgsegm(x86-64) = 4.8.0-2.fc38 opencv-bioinspired(x86-64) = 4.8.0-2.fc38 opencv-ccalib(x86-64) = 4.8.0-2.fc38 opencv-cvv(x86-64) = 4.8.0-2.fc38 opencv-datasets(x86-64) = 4.8.0-2.fc38 opencv-dnn_objdetect(x86-64) = 4.8.0-2.fc38 opencv-dnn_superres(x86-64) = 4.8.0-2.fc38 opencv-dpm(x86-64) = 4.8.0-2.fc38 opencv-face(x86-64) = 4.8.0-2.fc38 opencv-freetype(x86-64) = 4.8.0-2.fc38 opencv-fuzzy(x86-64) = 4.8.0-2.fc38 opencv-hdf(x86-64) = 4.8.0-2.fc38 opencv-hfs(x86-64) = 4.8.0-2.fc38 opencv-img_hash(x86-64) = 4.8.0-2.fc38 opencv-intensity_transform(x86-64) = 4.8.0-2.fc38 opencv-line_descriptor(x86-64) = 4.8.0-2.fc38 opencv-mcc(x86-64) = 4.8.0-2.fc38 opencv-optflow(x86-64) = 4.8.0-2.fc38 opencv-phase_unwrapping(x86-64) = 4.8.0-2.fc38 opencv-plot(x86-64) = 4.8.0-2.fc38 opencv-quality(x86-64) = 4.8.0-2.fc38 opencv-rapid(x86-64) = 4.8.0-2.fc38 opencv-reg(x86-64) = 4.8.0-2.fc38 opencv-rgbd(x86-64) = 4.8.0-2.fc38 opencv-saliency(x86-64) = 4.8.0-2.fc38 opencv-shape(x86-64) = 4.8.0-2.fc38 opencv-stereo(x86-64) = 4.8.0-2.fc38 opencv-structured_light(x86-64) = 4.8.0-2.fc38 opencv-superres(x86-64) = 4.8.0-2.fc38 opencv-surface_matching(x86-64) = 4.8.0-2.fc38 opencv-text(x86-64) = 4.8.0-2.fc38 opencv-tracking(x86-64) = 4.8.0-2.fc38 opencv-videostab(x86-64) = 4.8.0-2.fc38 opencv-viz(x86-64) = 4.8.0-2.fc38 opencv-wechat_qrcode(x86-64) = 4.8.0-2.fc38 opencv-ximgproc(x86-64) = 4.8.0-2.fc38 opencv-xobjdetect(x86-64) = 4.8.0-2.fc38 opencv-xphoto(x86-64) = 4.8.0-2.fc38
```

(Just to be perfectly clear, I'm only suggesting this change for F39+, but I am still running F38 (on x86_64) so that is how rpmspec expands it.)

I think we can go with this for rawhide , and check if nothing got broken ...

@sergio do you want to merge and build https://src.fedoraproject.org/rpms/opencv/pull-request/24 for rawhide or should I?

FEDORA-2023-1e8efb88d3 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1e8efb88d3

FEDORA-2023-1e8efb88d3 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.