Hi Fabio,
On 4/5/23 21:38, Fabio Valentini wrote:
On Wed, Apr 5, 2023 at 12:04 PM Zamir SUN zsun@fedoraproject.org wrote:
Hi,
I'm working on libtraceevent and libtracefs update. There will be soname bump happening to them. Namely,
libtraceevent.so 1.6.3 -> 1.7.2 libtracefs.so 1.5.0 -> 1.6.4
IIRC only kernel-tools (for perf and rtla) and trace-cmd depends on them. So I'm also copying their corresponding contacts.
As for libtraceevent, I've tried running trace-cmd/perf/rtla with the new version and they still works. So I've updated it in Rawhide, Fedora 38 and Fedora 37. They are now in Bodhi.
First I wanted to say that pushing soname bumps to stable releases is a bad idea, but then I checked, abd both 1.6.3 and 1.7.2 of libtraceevent provide the same soname (libtraceevent.so.1()(64bit)) so there's no soname bump after all :)
I agree it's bad idea to bump library in stable release, but that's really the only way I can find to fix a bug there. OTOH it only changes the minor version (1.6 to 1.7) and I've read the git commits and did some testing before updating which makes me feel it's safe. That's why I do such risky thing.
As for libtracefs I've built it in side tag f39-build-side-65890. I plan to update it in both Rawhide and Fedora 38 this week.
The same applies to libtracefs - the soname for both v1.5.0 and v1.6.4 is libtracefs.so.1()(64bit).
As for the soname change theory. I take it differently. Bumping from 1.6.x to 2.0.x is of course a soname change. But I've seen a couple of times even changing the 2nd number (for example, 1.6.3 to 1.7.x) causes issues in other libraries. That's why I decide to also announce the change, just in case it really affects something I did not notice.
Thanks for your reply and review.
Fabio