Bug 1082763
| Summary: | include userspace tools/lib/lockdep in kernel-tools* | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Ch. Eigler <fche> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, rhack | ||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | Bug | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. *** 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. *** |
Created attachment 881041 [details] lockdep build/package for rawhide kernel.spec The userspace lockdep library, though early, would still be nice to package.