From Fedora Project Wiki

(Adding draft for invalid-soname)
Line 1: Line 1:
 
 
The following metadata was found in MoinMoin that could not be converted
 
The following metadata was found in MoinMoin that could not be converted
 
to a useful value in MediaWiki:
 
to a useful value in MediaWiki:
Line 8: Line 7:
  
 
I really miss "official" info which is easy to link to for things I run into too often:
 
I really miss "official" info which is easy to link to for things I run into too often:
* incorrect-fsf-address
 
 
* debuginfo-without-sources
 
* debuginfo-without-sources
* invalid-soname
+
 
 +
invalid-soname draft
 +
 
 +
== invalid-soname ==
 +
The handling of this error depends on ld.so's load paths (the "linker paths") and whether it refers to a private or public library.
 +
 
 +
The linker paths is %{_libdir} + any path listed in /etc/ld.so.conf or in a file in /etc/ld.so.conf.d.
 +
 
 +
Public libraries are libs expected to be used by other packages, Other libraries e. g., plugins and functionality internal to the package are private.
 +
 
 +
We have four cases:
 +
* The library is public. Inform upstream about the issue and propose that they add or fixes versioning, possibly by sending a patch. Don't apply patch until it's merged upstream to avoid upgrade problems.
 +
* The library is stored outside the linker paths. In this case the error can be ignored.
 +
* The library is private and stored in a directory included in the linker paths. If possible, move the library to another directory outside the linker paths. This might require patching build scripts.
 +
* The library is private, stored in a directory included in the linker paths and can't be moved. Here,  the library must have a name unlikely to clash with other libraries. Filtering the Provides: to make sure the private library isn't visible should be considered.
 +
 
 +
The standard way to move a private library is to create a new directory under %{_libdir} e. g., /usr/lib/myapp. Don't list it in /etc/ld.so.conf files! Instead, use a rpath to let the application locate the library.
 +
 
 +
Filtering has some limitations, see [[#no-soname]]
 +
 
 +
See also:
 +
  [[#no-soname]]
 +
  [http://lists.fedoraproject.org/pipermail/devel/2012-April/166104.html This thread]

Revision as of 02:26, 23 April 2012

The following metadata was found in MoinMoin that could not be converted to a useful value in MediaWiki:

  •  : hack to omit unused-direct-shlib-dependencies
  • acl: Known:read,write All:read

I really miss "official" info which is easy to link to for things I run into too often:

  • debuginfo-without-sources

invalid-soname draft

invalid-soname

The handling of this error depends on ld.so's load paths (the "linker paths") and whether it refers to a private or public library.

The linker paths is %{_libdir} + any path listed in /etc/ld.so.conf or in a file in /etc/ld.so.conf.d.

Public libraries are libs expected to be used by other packages, Other libraries e. g., plugins and functionality internal to the package are private.

We have four cases:

  • The library is public. Inform upstream about the issue and propose that they add or fixes versioning, possibly by sending a patch. Don't apply patch until it's merged upstream to avoid upgrade problems.
  • The library is stored outside the linker paths. In this case the error can be ignored.
  • The library is private and stored in a directory included in the linker paths. If possible, move the library to another directory outside the linker paths. This might require patching build scripts.
  • The library is private, stored in a directory included in the linker paths and can't be moved. Here, the library must have a name unlikely to clash with other libraries. Filtering the Provides: to make sure the private library isn't visible should be considered.

The standard way to move a private library is to create a new directory under %{_libdir} e. g., /usr/lib/myapp. Don't list it in /etc/ld.so.conf files! Instead, use a rpath to let the application locate the library.

Filtering has some limitations, see #no-soname

See also:

 #no-soname
 This thread