Created attachment 881041 [details] lockdep build/package for rawhide kernel.spec The userspace lockdep library, though early, would still be nice to package.
A few comments/questions. I really dislike shipping unversioned .so libraries as the main deliverable. That provides no mechanism to avoid ABI/API conflicts in applications using the library. As you said, it's pretty early... Why would we ship liblockdep.a? That's going to require a static lib allowance from FESCo and seems unnecessary. Why wouldn't we ship the lockdep wrapper? We had a similar request (though I can't find a link to it at the moment) for libtraceevent.so and we said we were going to wait for a versioned shared library first. I would guess this falls into the same category.
> I really dislike shipping unversioned .so libraries as the main deliverable. Understood; shall we improvise a git-describe type version? > Why would we ship liblockdep.a? That's going to require a static lib > allowance from FESCo and seems unnecessary. Good point. > Why wouldn't we ship the lockdep wrapper? It is in %{_bindir} .. though it probably doesn't work as is due to LD_PRELOAD="./liblockdep.so" hardcoding therein. Maybe create a new one during %build/%install, based on the improvised versioned soname?
I'd rather upstream actually create a proper shared library and use -soname with a proper version string. Then liblockdep.so becomes a symlink in the -devel package, like every other shared library. I'll bug them about it.
*** Bug 1082816 has been marked as a duplicate of this bug. ***
http://thread.gmane.org/gmane.linux.kernel/1676007
Hi guys. I tried create whole separate package of liblockdep in bug bz#1084680. Should I close that bug as a duplicity?
(In reply to Robin Hack from comment #6) > Hi guys. I tried create whole separate package of liblockdep in bug > bz#1084680. Should I close that bug as a duplicity? Yeah, that's fine.
*** Bug 1084680 has been marked as a duplicate of this bug. ***