On 04/20/2012 06:16 PM, Toshio Kuratomi wrote:
On Fri, Apr 20, 2012 at 05:59:44PM +0200, Kevin Kofler wrote:
Toshio Kuratomi wrote:
* Private unversiond libs in %{_libdir}. -- I would consider this a
blocker unless shown that they have to be there (and I would patch the
build scripts to fix this if necessary).
Why is this a problem, assuming the name doesn't conflict with anything? (Of
course a generic name like libparser.so would be a problem.)
* Organizationally -- I wouldn't want it there because it serves a wholly
different purpose.
* Naming-conflict wise, it's easier to tell people on review to move private
libs on review than to find out later that there's a conlict and then have
to get two maintainres to decide whether some of their libs are private,
who is responsible for moving their libraries, etc.
* For rpm, it adds unnecessary provides which are not only potential
conflicts but also add bloat to the repodata that users have to download.
I suppose in strict answer to your question; not every reviewer would need
consider this a blocker. But if I was reviewing a package, I would
submit patches to make it use a private directory and expect that those
patches would be applied for approval and its one of the things Id see if
I was evaluating a reviewer and say, eh... I can see why you don't require
that but it does make me feel you're a little more sloppy than otherwise.
-Toshio
Hm... trying to summarize and expand to a more complete draft on how to
handle 'invalid-soname' warning:
----
If the warning is about a public library, upstream should be informed,
preferably with a patch. Don't apply patch until it's merged with
upstream for compatibility reasons. The unversioned so-file goes to a
binary package. (Are there situations when applying a patch is
preferable even when upstream don't?)
If the warning is about a private library stored outside the linker
paths, it can be ignored.
If the warning is about a private library in the linker paths we should
try hard to patch the package to move it outside the paths using e. g.,
a private dir under /usr/libx* and a rpath. Patches goes upstream.
If above is not possible and package needs to store a private library in
the linkers paths the library must have a name unlikely to clash with
others. In this situation, the package should be filtered to avoid
providing the private lib to other packages.
---
The last one, about filtering, is my own. For me, it seems like a
logical conclusion (?)
Thoughts? Should something like this go into "Common Rpmlint Issues" ?
--alec
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
