Docker is the one thing that works on MANY flavors of Linux.
If I want to provide a tool I want to spend my time on building the tool, not building an rpm, a snap, a deb, ...
The Docker build process is significantly easier. For example, I can just pull in NodeJS 20. I can't do that on Ubuntu. It's not available on packages.ubuntu.com.
Building a deb/snap/rpm is a whole other language to understand how dependencies are set up.
And then I need to test those. I've never even ran CentOS.
I’m assuming openjdk is versioned correctly and the name of the opencv package is opencv. I’m also assuming openjdk, replace openjdk with your jdk package name.
You would put this line in your rpm .spec file. Do you really think the above line is hard? Maybe the difficulty you have is in never have touched rpm. Start here: http://ftp.rpm.org/max-rpm/index.html
Yes that is already way too much extra work. And when those versions are not yet available to depend on? libheif, libaom and libraw needs latest versions and be built together.
That is an implementation detail, not a problem with rpm spec. When comcast builds rpms, the entire chain of required software is built with it. I should add: it is trivial to make integration tests to catch exactly what you describe. If the software is not built internally then the infra team ensures the required repos exist and dependencies match up to official repo rpms.
None of that has to do with the difficulty of rpm spec, but entirely with organizational planning. You do plan while building software.. right?
Also github does the exact same thing but with deb. It works in the real world. Quite well, too!
Docker is the one thing that works on MANY flavors of Linux.
If I want to provide a tool I want to spend my time on building the tool, not building an rpm, a snap, a deb, ...
The Docker build process is significantly easier. For example, I can just pull in NodeJS 20. I can't do that on Ubuntu. It's not available on packages.ubuntu.com.
Building a deb/snap/rpm is a whole other language to understand how dependencies are set up.
And then I need to test those. I've never even ran CentOS.