>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 <[email protected]> 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
