tango-cpp's upstream does not actually mandate omniorb 4.2.5. The project only sets a minimum version requirement. But anyway, the new release of tango-cpp is on the horizon, it's currently on rc4, and that one requires at least omniorb 4.3.0, satisfied by AUR/omniorb. And omniorb425 still violates AUR submission guidelines and Arch packaging guidelines. On 9 October 2023 12:53:50 GMT+02:00, Antonio Bartalesi <antonio.bartalesi@gmail.com> wrote:

Please ignore this deletion request, the package is needed by tango-cpp. Conflict is handled correctly and name is also ok.

On Thu, 5 Oct 2023 at 23:41, <notify@aur.archlinux.org> wrote:

...

MarsSeed [1] filed a deletion request for omniorb425 [2]:

This legacy version package is not needed anymore by other packages. And it conflicts with the newer AUR/omniorb.

(Also the pkgname does not conform to Arch packaging guidelines, as the attached number should mean major version, but this is not v425, but v4.2.5.)

[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/omniorb425/

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

https://gitlab.com/tango-controls/cppTango/-/merge_requests/1092 Support for omniorb 4.3.0 will only be added in cpptango 9.5.0 I won't reply again in this thread, I feel like I wasted enough of my time already. To the admin: please do not delete this package