Hide Forgot
Description of problem: I am working on updating the stp package to the latest version. It has picked up a few new dependencies, including one on the C portion of perl-Bit-Vector. In fact, /usr/share/doc/perl-Bit-Vector-7.1/README.txt mentions that it is "an efficient C library" with a perl interface. However, we don't have it packaged that way. It is a perl-only interface at the moment. Would you either break out the C portion, and create a -devel package, so that it can be used from C programs, or else give me the go-ahead to do so? Thanks. Version-Release number of selected component (if applicable): perl-Bit-Vector-7.1-5.fc15.x86_64 How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.