dublin-traceroute prereq 'libtins' version issues

[kylehutson]

I'm installing perfsonar-toolkit on a new AlmaLinux 9.2 host
After narrowing down the errors, it comes to this:

dnf install dublin-traceroute
Last metadata expiration check: 0:39:19 ago on Fri Sep 15 13:11:09 2023.
Error:
Problem: cannot install the best candidate for the job

• nothing provides libtins.so.4.4()(64bit) needed by dublin-traceroute-0.4.2-1.el9.x86_64

When I manually install libtins

yum list installed libtins
Installed Packages
libtins.x86_64 4.5-1.el9 @epel

I also symlinked /usr/lib64/libtins.so.4.4 to /usr/lib64/libtins.so.4.5, but as it appears to be looking for an installed version, rather than that the file exists/works, I can't get installation to continue.

[mfeit-internet2]

RPM's auto-dependency detector is known to do the wrong thing with some packages that works there's an upgrade. I've disabled it for this package and we'll release the fixed RPM with the upcoming bugfix release.

[loveshack]

I should probably have commented here rather than on the change: 9832ab2#commitcomment-127854981

[mfeit-internet2]

@loveshack Re. your comment:

I agree that we shouldn't have had to do this, but this put installations dead in the water until the fix bubbles out to EPEL (which it may have by now). This isn't the first time we've had to do it and, historically, it hasn't had any bad side effects because Red Hat normally doesn't breaki anything within the same major release.

Thanks for opening the Fedora ticket. That will solve the problem, but we're still stuck until that fix makes it out into EPEL, which doesn't appear to have happened yet.

I'm going to leave this open and we'll revisit it in the next couple of feature releases to see if we can go back to the right way.

[mfeit-internet2]

EPEL has fixed this; will be removed in 5.2.