| Summary: | RFE: expose the perl-Bit-Vector C library | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jerry James <loganjerry> | ||||
| Component: | perl-Bit-Vector | Assignee: | Marcela Mašláňová <mmaslano> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | mmaslano | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-03-29 15:12:10 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Jerry James
2011-07-13 22:50:06 UTC
Created attachment 513273 [details]
Proposed spec file
I'm attaching a proposed spec file to make the change I am requesting. Upstream unfortunately provides no support for building as a C library, hence the direct gcc invocation. This isn't as clean as I would like. It would be better if %{_libdir}/perl5/vendor_perl/auto/Bit/Vector/Vector.so was linked against %{_libdir}/libBitVector.so, rather than both of them containing the sources. There's no Makefile support for doing it this way, though, and I haven't figured out how to hack upstream's Makefile to do it that way.
Also, since I've been playing with RPM 4.9's filtering mechanism, I threw in some rules to use it instead of the existing script-based approach. The current approach isn't working, by the way. This is on a Fedora 15 machine:
$ rpm -q --provides perl-Bit-Vector
Vector.so()(64bit)
perl(Bit::Vector)
perl(Bit::Vector) = 7.1
perl(Bit::Vector::Overload) = 7.1
perl(Bit::Vector::String) = 7.1
perl-Bit-Vector = 7.1-5.fc15
perl-Bit-Vector(x86-64) = 7.1-5.fc15
What do I need to do to get some movement on this bug? It's blocking an update of the stp package. I had a lot of work with rebuild of perl. I'll fix it as first thing tomorrow. I promise :) I'm not sure what you are trying to do. This module was written with xs support to provide C library internally, but you should use it in Perl programmes. I don't want maintain workaround, which will differ from upstream and support it. This kind of changes must be discussed with upstream first: http://search.cpan.org/~stbey/Bit-Vector-7.1/ Perl modules doesn't have -devel packages. In case the module provide header files, they are installed with main package. How could be stp dependent on modified package? What happened is that the stp project, which is written in C, has imported constantbv.cpp and constantbv.h from the upstream Bit-Vector package. Given the Fedora policy of no bundled libraries, I thought we should attempt to expose the C internals of Bit-Vector, as well as the perl wrapper around those internals. After some digging, it appears that you are right about this not being supported by upstream. Or, rather, Bit-Vector upstream expects other projects to do exactly what the stp developers did: import the sources directly into their projects, rather than build a library. I'm not sure what to do. I guess I should just close this bug, update stp, and stop worrying about it. If you have any proposal for upstream, then please try to contact them. I don't have any proposals about it. I'll try to create a Makefile that will do the job and then submit it upstream. Thanks for your attention. |