Some gems put the ext/ source directory inside the gem, causing 2 types of warning/errors: - the source .c files get inside the gem, causing rpmlint to complain - sometimes the library gets duplicated in ext and lib /usr/lib64/ruby/gems/1.8/gems/nokogiri-1.3.3/lib/nokogiri/nokogiri.so /usr/lib64/ruby/gems/1.8/gems/nokogiri-1.3.3/ext/nokogiri/nokogiri.so because it is build in one and installed in the other. The ext/ one is useless and ignored, but makes the buildid extractor dizzy when creating debuginfo packages. As all rpm gems contain: %gem_install %{S:0} %gem_cleanup Shouldn't %gem_cleanup do rm -rf %{buildroot}/%{_libdir}/ruby/gems/%{rb_ver}/gems/%{mod_name}-%{version}/ext ? (I am doing this in a couple of gems already) -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org
On 2009-10-19 12:18:00 +0200, Duncan Mac-Vicar Prett wrote:
Some gems put the ext/ source directory inside the gem, causing 2 types of warning/errors:
- the source .c files get inside the gem, causing rpmlint to complain - sometimes the library gets duplicated in ext and lib
/usr/lib64/ruby/gems/1.8/gems/nokogiri-1.3.3/lib/nokogiri/nokogiri.so /usr/lib64/ruby/gems/1.8/gems/nokogiri-1.3.3/ext/nokogiri/nokogiri.so
because it is build in one and installed in the other. The ext/ one is useless and ignored, but makes the buildid extractor dizzy when creating debuginfo packages.
As all rpm gems contain:
%gem_install %{S:0} %gem_cleanup
Shouldn't %gem_cleanup do rm -rf %{buildroot}/%{_libdir}/ruby/gems/%{rb_ver}/gems/%{mod_name}-%{version}/ext ?
(I am doing this in a couple of gems already)
no. deleting the 2nd .so in ext might work (but we need to check if it isnt a link) but i would like to keep the source so people can rebuild it locally as it would be a gem installed with "gem install". darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org
On Monday 19 October 2009 14:02:52 Marcus Rueckert wrote:
but i would like to keep the source so people can rebuild it locally as it would be a gem installed with "gem install".
What is the usecase of rebuilding locally? It would result in the same binary, unless you apply a patch, and if the patch is applied the binary will no longer match the rpm verification. then we need to tell rpmlint, because one gets the error/warning source files in non-devel package. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org
On 2009-10-19 15:15:26 +0200, Duncan Mac-Vicar Prett wrote:
On Monday 19 October 2009 14:02:52 Marcus Rueckert wrote:
but i would like to keep the source so people can rebuild it locally as it would be a gem installed with "gem install".
What is the usecase of rebuilding locally? It would result in the same binary, unless you apply a patch, and if the patch is applied the binary will no longer match the rpm verification.
then we need to tell rpmlint, because one gets the error/warning source files in non-devel package.
it is an rpmlint warning. it doesnt make your package fail. as an autobuild team member i appreciate that you thought about solving the problem. but it really isnt needed in this case. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org
participants (2)
-
Duncan Mac-Vicar Prett -
Marcus Rueckert