You are wrong, please read the PKGBUILD for tango-cpp, and see that omniorb needs to be < 4.3.0.
No, it is you who is wrong. PKGBUILD is not upstream. Upstream's CMakeLists.txt only contains a comment, citing a minimum version for omniorb: " omniORB>=4.2.4 is required for compilation in C++17 (or better) mode. " [a]
Also this is used in production
Just because some admins don't update a shared library in production is not a good enough reason to not allow AUR users to use the latest stable omniorb with the latest stable tango-cpp.
Finally please do read again the guidelines about naming, or take as example packages such as python310, which is clearly not version 310 of python
Please don't cite a wrong example. AUR/python310 also violates Arch package naming guidelines. But what the latter does not violate but omniorb425 does is: python310 does not conflict with the main python package, whereas omniorb425 does conflict with omniorb. If you really want to (unnecessarily) stick to this old version, resubmit a non-conflicting package. I suggest the name to be omniorb-4.2, to allow the (hypothetical) possibility of updating the third version point (4.2.6 to 4.2.7 if there ever will be such). On 9 October 2023 13:09:12 GMT+02:00, Antonio Bartalesi <antonio.bartalesi@gmail.com> wrote:
You are wrong, please read the PKGBUILD for tango-cpp, and see that omniorb needs to be < 4.3.0. Also this is used in production and having a new version "on the horizon" does not justify breaking the current installation. Finally please do read again the guidelines about naming, or take as example packages such as python310, which is clearly not version 310 of python
[a]: https://gitlab.com/tango-controls/cppTango/-/blob/9.4.2/CMakeLists.txt#L15