Fedora Account System
Red Hat Associate
Red Hat Customer
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. ***
This report has not received an update in over 90 days. If this issue is still relevant to you, please do not hesitate to update this report with any relevant details on recent investigative steps or changes and we will absolutely work to understand how to best move forward. Otherwise, this bug report will need to be closed in 30 days. No worries, however; should you need still assistance after the report is closed, please do not hesitate to create a new bug report referencing this report and with any new details on the matter. NOTE: This is an automated mass update.