https://bugzilla.redhat.com/show_bug.cgi?id=1147013 --- Comment #37 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.michael@xxxxxxx> --- > https://github.com/rofl0r/proxychains-ng/issues/46 That request is difficult to understand. It doesn't explain *why* a version is requested, and it doesn't explain what "such problems" refers to. An unversioned shared lib is not a problem. Unless it changes ABI often, in which case automatic dependencies on the unversioned lib soname would be very weak. It is also wrong to claim "unversioned so file which usually goes in -dev, -devel packages". There is no such thing as "usually" for .so files. It really depends on *how* (and when) such .so files (or symlinks) are used: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages Versioning shared libs does not solve any problem related to -devel packages. For example, imagine you had multiple versions of a library. You still could not have two non-versioned .so symlinks in the -devel packages, because they would conflict with eachother by pointing at different link targets. Another solution for that would be needed (such as hiding files from default search paths). > move libproxychains4.so to some application-private directory > (like %_libdir/%name or so) That would move it outside runtime linker's search path. Stuff like LD_PRELOAD=libproxychains4.so would fail and would need to be patched to add the full path. Not good if it were not done by upstream. [...] IMHO, there is nothing wrong with keeping libproxychains4.so in %_libdir. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review