On 04/20/2012 05:09 PM, Toshio Kuratomi wrote:
On Fri, Apr 20, 2012 at 04:32:59PM +0200, Alec Leamas wrote:On 04/20/2012 04:08 PM, Kevin Kofler wrote:As far as I know, invalid-soname does not match any requirement in our packaging guidelines.To my understanding, this is not really clear. From [1] I find ( thanks to tibbs):As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries. These files are usually plugins or modular functionality specific to an application, and are not located in the ld library paths or cache. This means that they are not located directly in /usr/lib or /usr/lib64, or in a directory listed as a library path in /etc/ld.so.conf (or an /etc/ld.so.conf.d/config file). Usually, these unversioned shared objects can be found in a dedicated subdirectory under /usr/lib or /usr/lib64 (e.g. /usr/lib/purple-2/ is the plugin directory used for libpurple applications). In these cases, the unversioned shared objects do not need to be placed in a -devel package.I read those lines as "unversioned libs should be outside of ld.so's paths" - placing them in a -devel package makes no sense. Also, my initial discussion on #fedora-devel pointed in the same direction.I would agree more with your initial interpretation. The libraries you are dealing with are private to the app, correct? If so, create a directory like %{_libdir}/APPLICATION and place the libraries into that directory makes sense. If these are libraries (rather than modules that are being dlopen'd) you would further need to build the application so that it knows to look in that directory (this would be where rpath is used).Unversioned shared libraries are bad, but inventing a library version can lead to conflicts with future upstream releases for public libraries, and is just not worth it at all for private ones. There's no need for a soname version if the library comes from the same package as the only user(s) of it. Kevin KoflerLooks fine to me. Anyone else? Should the private lib be filtered in this situation? Thanks for input.!I would not consider this a hard and fast rule, but it is generally good advice. -Toshio Thanks again. Following this advice when packaging makes perfect sense to me. Still, when reviewing, my question is how hard I should push it. If I understand Kevin correct I shouldn't push it all (?). Is your position that private, unversioned libs in /usr/lib* is a problem, but not a blocker? |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel