https://bugzilla.redhat.com/show_bug.cgi?id=2091317 --- Comment #3 from Stewart Smith <trawets@xxxxxxxxxx> --- Have the shared library be unversioned was a conscious choice a number of years back (OMG it's actually 9 years) as it doesn't really make any sense to version it as the use case is LD_PRELOAD rather than ever directly linking against. A major version bump would mean "We just threw out POSIX or broke kernel/userspace ABI" and minor bumps aren't visible as applications aren't linking directly with it. libeatmydata is more like `fakeroot`, `libkeepalive`, `preeny`, and `trickle`, which are also LD_PRELOAD libraries packaged for Fedora which also do not have versioned libraries. Mind you, `libfaketime` is a packaged LD_PRELOAD library that *does* have a versioned library (just a .so.1). So I think that since (at least so far) the majority of LD_PRELOAD focused libraries packaged in Fedora have been erring on the side of having unversioned libraries, it should be okay for libeatmydata to also be this way. I went with putting it in `libeatmydata` as a package rather than putting the .so in a devel package as it's not a library that's ever used for development, it's the Actual Thing you want to run. The `eatmydata` script just works out where `libeatmydata.so` is in order to LD_PRELOAD it. There seems to be a mix of existing LD_PRELOAD focused packages in Fedora where some have helper scripts and some don't. A least for `fakeroot` it is split between the `fakeroot` package with the helper script and `fakeroot-libs` with the libraries, although `libfaketime` just bundles everything in one. So, I agree on %license, BuildRequires: gcc, and attr/defattr and will spin a -3, but think the library should remain unversioned and not be in a -devel package, instead remaining in the libeatmydata package. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091317 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
