Sorry, it doesn't seem like my original response made it through (at least not according to the ruby-sig archive http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/thread.html). Resending.
-Mo
-------- Original Message -------- Subject: Re: ruby 1.8.7.x for rawhide Date: Fri, 18 Jun 2010 12:44:56 -0400 From: Mohammed Morsi mmorsi@redhat.com To: Ruby SIG mailing list ruby-sig@lists.fedoraproject.org CC: Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp, ruby-owner@fedoraproject.org
Hey Mamoru,
Appreciate the efforts. I am also working towards Ruby 1.8.7 on Fedora, just released a SRPM/SPEC a few days ago that I was working on
http://mo.morsi.org/blog/node/318
Just fyi, we're also going to need this patch
http://redmine.ruby-lang.org/repositories/diff/ruby-187?rev=27408
To get rails 3.0.0 working against Ruby 1.8.7p149
http://redmine.ruby-lang.org/issues/show/2557
I'm currently working on bundling Rails 3 into rpms and creating a Fedora based virtual appliance w/ Ruby 1.8.7 on it, similar to the one I released w/ Ruby 1.9, to make testing software against multiple versions of Ruby on Fedora as simple as possible. After that I'm planning on setting up an automated test system to test the various Ruby packages we have in Fedora against each appliance.
Stay tuned for updtes.
-Mo
Hello, Mohammed
Mohammed Morsi wrote, at 06/19/2010 02:03 AM +9:00:
Sorry, it doesn't seem like my original response made it through (at least not according to the ruby-sig archive http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/thread.html). Resending.
-Mo
-------- Original Message -------- Subject: Re: ruby 1.8.7.x for rawhide Date: Fri, 18 Jun 2010 12:44:56 -0400 From: Mohammed Morsi mmorsi@redhat.com To: Ruby SIG mailing list ruby-sig@lists.fedoraproject.org CC: Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp, ruby-owner@fedoraproject.org
Hey Mamoru,
Appreciate the efforts. I am also working towards Ruby 1.8.7 on Fedora, just released a SRPM/SPEC a few days ago that I was working on
http://mo.morsi.org/blog/node/318
Thank you for your another work for ruby 1.8.7. Hopely we can merge our efforts altogether and import ruby187 to (at least) rawhide soon.
By the way I just looked at your srpm (on your blog) quickly and also tried binary rpms rebuilt your srpm quickly. I thinking defining %ruby_sitearch or so is preferred because we already use such macros in ruby related srpms. For rawhide I think we should create /etc/rpm/macros.ruby18 . However, with ruby rpms rebuilt from your srpm, ruby returns: ---------------------------------------------------------- mock-chroot> ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-linux] mock-chroot> ruby -e 'puts $:'
/usr/lib/ruby//site_ruby /usr/lib/ruby//site_ruby /usr/lib/ruby//site_ruby
. mock-chroot> ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]' ruby: no such file to load -- rbconfig (LoadError) ----------------------------------------------------------
On the other hand, from rpms rebuilt from my srpm: ---------------------------------------------------------- mock-chroot> ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-linux] mock-chroot> ruby -e 'puts $:' /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8/i386-linux /usr/lib/ruby/site_ruby /usr/lib/site_ruby/1.8 /usr/lib/site_ruby/1.8/i386-linux /usr/lib/site_ruby /usr/lib/ruby/vendor_ruby/1.8 /usr/lib/ruby/vendor_ruby/1.8/i386-linux /usr/lib/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i386-linux . mock-chroot> ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]' /usr/lib/ruby/site_ruby/1.8/i386-linux ----------------------------------------------------------
Also, currently we usually define %ruby_sitearch as $(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]'), which currently returns as above (i.e. /usr/lib/ruby/site_ruby/1.8/i386-linux), and I think we shouldn't change these paths with the update from 1.8.6.x to 1.8.7.x (when importing 1.9.x ruby in parallel, I think we can consider to change these paths in ruby 1.9).
Just fyi, we're also going to need this patch
http://redmine.ruby-lang.org/repositories/diff/ruby-187?rev=27408To get rails 3.0.0 working against Ruby 1.8.7p149
http://redmine.ruby-lang.org/issues/show/2557
Well, I just git-cloned rails.git and it seems that unicode_database.rb can no longer be found in rails tree. Instead I found unicode_database.rb in activesupport 2.3.5 but it won't cause crash even with my 1.8.7.249 srpm - maybe because I use "-fno-strict-aliasing". However anyway I applied this patch and it can be found on:
http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/ (currently only rebuilt for rawhide, however srpm can also be found here)
I'm currently working on bundling Rails 3 into rpms and creating a Fedora based virtual appliance w/ Ruby 1.8.7 on it, similar to the one I released w/ Ruby 1.9, to make testing software against multiple versions of Ruby on Fedora as simple as possible. After that I'm planning on setting up an automated test system to test the various Ruby packages we have in Fedora against each appliance.
Thank you!
Stay tuned for updtes.
-Mo
Regards, Mamoru
On 06/18/2010 03:48 PM, Mamoru Tasaka wrote:
Hello, Mohammed
Mohammed Morsi wrote, at 06/19/2010 02:03 AM +9:00:
Sorry, it doesn't seem like my original response made it through (at least not according to the ruby-sig archive http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/thread.html). Resending.
-Mo
-------- Original Message -------- Subject: Re: ruby 1.8.7.x for rawhide Date: Fri, 18 Jun 2010 12:44:56 -0400 From: Mohammed Morsimmorsi@redhat.com To: Ruby SIG mailing listruby-sig@lists.fedoraproject.org CC: Mamoru Tasakamtasaka@ioa.s.u-tokyo.ac.jp, ruby-owner@fedoraproject.org
Hey Mamoru,
Appreciate the efforts. I am also working towards Ruby 1.8.7 onFedora, just released a SRPM/SPEC a few days ago that I was working on
http://mo.morsi.org/blog/node/318Thank you for your another work for ruby 1.8.7. Hopely we can merge our efforts altogether and import ruby187 to (at least) rawhide soon.
By the way I just looked at your srpm (on your blog) quickly and also tried binary rpms rebuilt your srpm quickly. I thinking defining %ruby_sitearch or so is preferred because we already use such macros in ruby related srpms. For rawhide I think we should create /etc/rpm/macros.ruby18 . However, with ruby rpms rebuilt from your srpm, ruby returns:
I readded the macros you mentioned to my specfile.
mock-chroot> ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-linux] mock-chroot> ruby -e 'puts $:'
/usr/lib/ruby//site_ruby /usr/lib/ruby//site_ruby /usr/lib/ruby//site_ruby
Sorry for the delay, uploaded a new SRPM with these path issues fixed. All the directories currently present on the path are now there again, as well a bunch of new '1.8.7' subdirs in preperation for the parallel installable ruby stacks. The new srpm can be found here:
http://mo.morsi.org/files/ruby-1.8.7.249-2.fc13.src.rpm
. mock-chroot> ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]' ruby: no such file to load -- rbconfig (LoadError)
On the other hand, from rpms rebuilt from my srpm:
mock-chroot> ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-linux] mock-chroot> ruby -e 'puts $:' /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8/i386-linux /usr/lib/ruby/site_ruby /usr/lib/site_ruby/1.8 /usr/lib/site_ruby/1.8/i386-linux /usr/lib/site_ruby /usr/lib/ruby/vendor_ruby/1.8 /usr/lib/ruby/vendor_ruby/1.8/i386-linux /usr/lib/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i386-linux
Running this on a 64 bit F13 install, also yields the following dirs
/usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby
The only thing is the /usr/lib64/site_ruby dir doesn't exist (the ruby package in Fedora doesn't provide it apparently, unless I'm mistaken), so I omitted these entries. If this is a mistake, they can be readded easily and the rpm spec changed to generate that dir.
. mock-chroot> ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]' /usr/lib/ruby/site_ruby/1.8/i386-linux
Also, currently we usually define %ruby_sitearch as $(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]'), which currently returns as above (i.e. /usr/lib/ruby/site_ruby/1.8/i386-linux), and I think we shouldn't change these paths with the update from 1.8.6.x to 1.8.7.x (when importing 1.9.x ruby in parallel, I think we can consider to change these paths in ruby 1.9).
This was due to the missing lib paths, now rbconfig loads fine.
Just fyi, we're also going to need this patch
http://redmine.ruby-lang.org/repositories/diff/ruby-187?rev=27408To get rails 3.0.0 working against Ruby 1.8.7p149
http://redmine.ruby-lang.org/issues/show/2557Well, I just git-cloned rails.git and it seems that unicode_database.rb can no longer be found in rails tree. Instead I found unicode_database.rb in activesupport 2.3.5 but it won't cause crash even with my 1.8.7.249 srpm - maybe because I use "-fno-strict-aliasing". However anyway I applied this patch and it can be found on:
http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/ (currently only rebuilt for rawhide, however srpm can also be found here)
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
-Mo
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Thanks for the new version. I too am interested in this, and based on your work, have eliminated most of the complaints from rpmlint and made a few other improvements. Here are the first few changes that affect only your spec file:
summary: remove trailing blanks placate rpmlint ruby_* definitions: do not use trailing slashes in directory names _normalized_cpu: simplify definition
From e4fbf5ea1b44a77957733c80df55a98706da4785 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyering@redhat.com Date: Tue, 22 Jun 2010 12:31:31 +0200 Subject: [PATCH 1/4] remove trailing blanks
--- spec | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/spec b/spec index 4f90823..8751612 100644 --- a/spec +++ b/spec @@ -12,8 +12,8 @@ %{!?ruby_sitearch: %global ruby_sitearch %{ruby_vendorarch}site_ruby}
# for compatability w/ macros defined in 1.8.6 rpm spec -%global sitedir %{ruby_sitearch} -%global sitedir2 %{ruby_sitelib} +%global sitedir %{ruby_sitearch} +%global sitedir2 %{ruby_sitelib}
%define _normalized_cpu %(echo `echo %{_target_cpu} | sed 's/^ppc/powerpc/' | sed -e 's|i.86|i386|'`) %define tk_using_svn_number 27738 @@ -29,8 +29,8 @@ License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: ncurses ncurses-devel gdbm gdbm-devel -BuildRequires: glibc-devel tcl-devel tk-devel libX11-devel +BuildRequires: ncurses ncurses-devel gdbm gdbm-devel +BuildRequires: glibc-devel tcl-devel tk-devel libX11-devel BuildRequires: autoconf gcc unzip openssl-devel db4-devel byacc BuildRequires: bison BuildRequires: emacs @@ -479,7 +479,7 @@ rm -rf $RPM_BUILD_ROOT
* Thu Jul 23 2009 Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp - 1.8.6.369-2 - Make sure that readline.so is linked against readline 5 because - Ruby is under GPLv2 + Ruby is under GPLv2
* Sat Jun 20 2009 Jeroen van Meeuwen kanarip@fedoraproject.org - 1.8.6.369-1 - New patchlevel fixing CVE-2009-1904
On 06/22/2010 06:44 AM, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Thanks for the new version. I too am interested in this, and based on your work, have eliminated most of the complaints from rpmlint and made a few other improvements. Here are the first few changes that affect only your spec file:
summary: remove trailing blanks placate rpmlint ruby_* definitions: do not use trailing slashes in directory names _normalized_cpu: simplify definition
I integrated all these into the spec and bumped the version / rereleased it. It can be found here
http://mo.morsi.org/files/ruby-1.8.7.249-3.fc13.src.rpm
-Mo
Mohammed Morsi wrote:
On 06/22/2010 06:44 AM, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Thanks for the new version. I too am interested in this, and based on your work, have eliminated most of the complaints from rpmlint and made a few other improvements. Here are the first few changes that affect only your spec file:
summary: remove trailing blanks placate rpmlint ruby_* definitions: do not use trailing slashes in directory names _normalized_cpu: simplify definition
I integrated all these into the spec and bumped the version / rereleased it. It can be found here
Thanks. Not new, but just to confirm...
With your new path setup, I see this (from -2):
$ ruby -e 'puts $:' /usr/lib64/ruby/site_ruby/1.8.7 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8.7/x86_64-linux /usr/lib64/ruby/site_ruby /usr/lib/ruby/site_ruby/1.8.7 /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby /usr/lib64/ruby//1.8.7 /usr/lib64/ruby//1.8 /usr/lib64/ruby//1.8.7/x86_64-linux /usr/lib64/ruby/ /usr/lib/ruby//1.8.7 /usr/lib/ruby//1.8 /usr/lib/ruby/ .
Even removing the 1.8.7 lines, trailing slashes and s,//,/, I still see differences with the reference, 1.8.6 path:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .
I.e., with your 1.8.7, we'd now search /usr/lib/ruby/site_ruby/1.8 6th. With 1.8.6, we search it first.
Is this change deliberate?
On 06/22/2010 03:00 PM, Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 06:44 AM, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Thanks for the new version. I too am interested in this, and based on your work, have eliminated most of the complaints from rpmlint and made a few other improvements. Here are the first few changes that affect only your spec file:
summary: remove trailing blanks placate rpmlint ruby_* definitions: do not use trailing slashes in directory names _normalized_cpu: simplify definition
I integrated all these into the spec and bumped the version / rereleased it. It can be found here
Thanks. Not new, but just to confirm...
With your new path setup, I see this (from -2):
$ ruby -e 'puts $:' /usr/lib64/ruby/site_ruby/1.8.7 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8.7/x86_64-linux /usr/lib64/ruby/site_ruby /usr/lib/ruby/site_ruby/1.8.7 /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby /usr/lib64/ruby//1.8.7 /usr/lib64/ruby//1.8 /usr/lib64/ruby//1.8.7/x86_64-linux /usr/lib64/ruby/ /usr/lib/ruby//1.8.7 /usr/lib/ruby//1.8 /usr/lib/ruby/ .Even removing the 1.8.7 lines, trailing slashes and s,//,/, I still see differences with the reference, 1.8.6 path:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .I.e., with your 1.8.7, we'd now search /usr/lib/ruby/site_ruby/1.8 6th. With 1.8.6, we search it first.
Is this change deliberate?
I could be wrong, but I don't think the search path order matters so much here, since what goes into each of these dirs is pretty well defined and disparate. So long as all the required paths are there, whatever required modules will be loaded correctly.
If I'm wrong about this, someone please correct me. If I am, I believe this can be easily fixed by changing the order which they are pushed onto the include path in the ruby-1.8.7-lib-paths patch
-Mo
On Tue, 2010-06-22 at 15:09 -0400, Mohammed Morsi wrote:
I could be wrong, but I don't think the search path order matters so much here, since what goes into each of these dirs is pretty well defined and disparate. So long as all the required paths are there, whatever required modules will be loaded correctly.
If I'm wrong about this, someone please correct me. If I am, I believe this can be easily fixed by changing the order which they are pushed onto the include path in the ruby-1.8.7-lib-paths patch
Please be very careful with any changes to the search path - while we _think_ we know where people put stuff, changing the order in which directories will be searched can break people's applications in very subtle ways.
Also, please do not add directories to the search path - if we want stuff like /usr/lib/ruby/site_ruby/1.8.7 on the search path, we also need to explain in the packaging guidelines what should and should not go there. That's a longer conversation.
For this update, I'd much prefer if we'd keep the search path exactly the same as it was in 1.8.6.
David
David Lutterkort wrote:
On Tue, 2010-06-22 at 15:09 -0400, Mohammed Morsi wrote:
I could be wrong, but I don't think the search path order matters so much here, since what goes into each of these dirs is pretty well defined and disparate. So long as all the required paths are there, whatever required modules will be loaded correctly.
If I'm wrong about this, someone please correct me. If I am, I believe this can be easily fixed by changing the order which they are pushed onto the include path in the ruby-1.8.7-lib-paths patch
Please be very careful with any changes to the search path - while we _think_ we know where people put stuff, changing the order in which directories will be searched can break people's applications in very subtle ways.
Also, please do not add directories to the search path - if we want stuff like /usr/lib/ruby/site_ruby/1.8.7 on the search path, we also need to explain in the packaging guidelines what should and should not go there. That's a longer conversation.
For this update, I'd much prefer if we'd keep the search path exactly the same as it was in 1.8.6.
This makes me think there is no compelling demand for the additional search path directories or for a change in ordering. Thus, I agree wholeheartedly.
On 06/22/2010 06:05 PM, David Lutterkort wrote:
<snip> For this update, I'd much prefer if we'd keep the search path exactly the same as it was in 1.8.6.
David
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Apologize for the delay, trying to juggle several of these ruby tasks at once (rails 2.3.8 and 3.0.0 rpms are in the works, and are almost completed)
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to what it was in Ruby 1.8.6.
http://mo.morsi.org/files/ruby-1.8.7.249-4.fc13.src.rpm
There is one major change, as noted before even though the Ruby 1.8.6 rpm included /usr/lib64/site_ruby in the search path, this directory does not exist and is not created / provided by the rpm, so I omitted it. If there is a valid reason for its inclusion, it can be readded, but the RPM itself should be updated to generate and own it. (Also the 1.8.7 subdirs for the parallel stacks in included, but commented out with a note to uncomment when needed)
I didn't change the approach to the multilib patch as there doesn't seem to yet be a consensus as the best way to conditionally apply it. I honestly can go whichever way so long as the final solution is understandable / standards compliant.
Finally, IMO i think we should be basing our work off my latest SRPM. I spent a lot of time removing uneeded cruft and consolidating related bits together, and I think it will provide the simplest way moving forward (especially with the parallel stacks stuff)
-Mo
Mohammed Morsi wrote:
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to what it was in Ruby 1.8.6.
You beat me to it. Thanks.
There is one major change, as noted before even though the Ruby 1.8.6 rpm included /usr/lib64/site_ruby in the search path, this directory does not exist and is not created / provided by the rpm, so I omitted it. If there is a valid reason for its inclusion, it can be readded,
I confirm that the paths containing /usr/lib64/site_ruby are removed but the rest are in order:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:'|sdiff -w78 orig-path - /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 < /usr/lib64/site_ruby/1.8/x86_64-linux < /usr/lib64/site_ruby < /usr/lib/ruby/1.8 /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux /usr/lib64/ruby/1.8/x86_64-linux . .
I think it would be prudent to include all three. That they are listed in ruby's default path is reason enough. That may have encouraged some people to create and use one or more of the directories. Whether the 1.8.6 rpm actually created/owned them isn't the issue. People may be relying on those being in ruby's default search path.
but the RPM itself should be updated to generate and own it. (Also the 1.8.7 subdirs for the parallel stacks in included, but commented out with a note to uncomment when needed)
I didn't change the approach to the multilib patch as there doesn't seem to yet be a consensus as the best way to conditionally apply it. I honestly can go whichever way so long as the final solution is understandable / standards compliant.
I see you are still using this approach:
%build export LIB_PREFIX=%{_lib}
Using that approach causes the "make ... && cd r*9/r*9 && make ..." idiom to subtly malfunction if it ends up running mkconfig.rb.
Finally, IMO i think we should be basing our work off my latest SRPM. I spent a lot of time removing uneeded cruft and consolidating related bits together, and I think it will provide the simplest way moving forward (especially with the parallel stacks stuff)
One more nit in your spec file:
------------------ %configure \ ... --with-sitearchdir='%{ruby_sitearch}' \ --with-vendordir='%{ruby_vendorlib}' \ --with-vendorarchdir='%{ruby_vendorarch}' \
# For example ext/socket/extconf.rb uses try_run (for getaddrinfo test), ------------------
Currently that final trailing slash doesn't cause trouble, but it'd be better to remove it, in case someone accidentally adds something intended to be a separate statement right after it.
On 06/23/2010 04:49 PM, Jim Meyering wrote:
Mohammed Morsi wrote:
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to what it was in Ruby 1.8.6.
You beat me to it. Thanks.
There is one major change, as noted before even though the Ruby 1.8.6 rpm included /usr/lib64/site_ruby in the search path, this directory does not exist and is not created / provided by the rpm, so I omitted it. If there is a valid reason for its inclusion, it can be readded,
I confirm that the paths containing /usr/lib64/site_ruby are removed but the rest are in order:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:'|sdiff -w78 orig-path - /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8< /usr/lib64/site_ruby/1.8/x86_64-linux< /usr/lib64/site_ruby< /usr/lib/ruby/1.8 /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux /usr/lib64/ruby/1.8/x86_64-linux . .
I think it would be prudent to include all three. That they are listed in ruby's default path is reason enough. That may have encouraged some people to create and use one or more of the directories. Whether the 1.8.6 rpm actually created/owned them isn't the issue. People may be relying on those being in ruby's default search path.
Readded, though honestly I'm not a fan of this reasoning. If its not in the Fedora / Ruby guidelines, it's not supported and thus we shouldn't add the additional complexity. Furthermore this approach would result in none of the paths ever changing, which obviously we don't want. Going forward we should identify only the paths that are supported and only include those.
but the RPM itself should be updated to generate and own it. (Also the 1.8.7 subdirs for the parallel stacks in included, but commented out with a note to uncomment when needed)
I didn't change the approach to the multilib patch as there doesn't seem to yet be a consensus as the best way to conditionally apply it. I honestly can go whichever way so long as the final solution is understandable / standards compliant.
I see you are still using this approach:
%build export LIB_PREFIX=%{_lib}
Using that approach causes the "make ...&& cd r*9/r*9&& make ..." idiom to subtly malfunction if it ends up running mkconfig.rb.
Done, changed it to use your patch.
Finally, IMO i think we should be basing our work off my latest SRPM. I spent a lot of time removing uneeded cruft and consolidating related bits together, and I think it will provide the simplest way moving forward (especially with the parallel stacks stuff)
One more nit in your spec file:
%configure \ ... --with-sitearchdir='%{ruby_sitearch}' \ --with-vendordir='%{ruby_vendorlib}' \ --with-vendorarchdir='%{ruby_vendorarch}' \
# For example ext/socket/extconf.rb uses try_run (for getaddrinfo test),
Currently that final trailing slash doesn't cause trouble, but it'd be better to remove it, in case someone accidentally adds something intended to be a separate statement right after it.
Done.
New SRPM uploaded:
http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm
-Mo
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
On 06/23/2010 04:49 PM, Jim Meyering wrote:
Mohammed Morsi wrote:
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to what it was in Ruby 1.8.6.
You beat me to it. Thanks.
There is one major change, as noted before even though the Ruby 1.8.6 rpm included /usr/lib64/site_ruby in the search path, this directory does not exist and is not created / provided by the rpm, so I omitted it. If there is a valid reason for its inclusion, it can be readded,
I confirm that the paths containing /usr/lib64/site_ruby are removed but the rest are in order:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:'|sdiff -w78 orig-path - /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8< /usr/lib64/site_ruby/1.8/x86_64-linux< /usr/lib64/site_ruby< /usr/lib/ruby/1.8 /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux /usr/lib64/ruby/1.8/x86_64-linux . .
I think it would be prudent to include all three. That they are listed in ruby's default path is reason enough. That may have encouraged some people to create and use one or more of the directories. Whether the 1.8.6 rpm actually created/owned them isn't the issue. People may be relying on those being in ruby's default search path.
Readded, though honestly I'm not a fan of this reasoning. If its not in the Fedora / Ruby guidelines, it's not supported and thus we shouldn't add the additional complexity. Furthermore this approach would result in none of the paths ever changing, which obviously we don't want. Going forward we should identify only the paths that are supported and only include those.
We need not change these (i.e. paths) with the upgrade of 1.8.6.x -> 1.8.7.x. We just ensure that everything just go well with only ruby rpm (and its subpackages) upgraded from 1.8.6.x to 1.8.7.x without trouble.
And, anyway with ruby 1.9 (which currently kanarip is trying to package), there is a big big change.
New SRPM uploaded:
Anyway I appreciate your contribution.
Regards, Mamoru
On 06/24/2010 12:28 AM, Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
On 06/23/2010 04:49 PM, Jim Meyering wrote:
Mohammed Morsi wrote:
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to what it was in Ruby 1.8.6.
You beat me to it. Thanks.
There is one major change, as noted before even though the Ruby 1.8.6 rpm included /usr/lib64/site_ruby in the search path, this directory does not exist and is not created / provided by the rpm, so I omitted it. If there is a valid reason for its inclusion, it can be readded,
I confirm that the paths containing /usr/lib64/site_ruby are removed but the rest are in order:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:'|sdiff -w78 orig-path - /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8< /usr/lib64/site_ruby/1.8/x86_64-linux< /usr/lib64/site_ruby< /usr/lib/ruby/1.8 /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux /usr/lib64/ruby/1.8/x86_64-linux . .
I think it would be prudent to include all three. That they are listed in ruby's default path is reason enough. That may have encouraged some people to create and use one or more of the directories. Whether the 1.8.6 rpm actually created/owned them isn't the issue. People may be relying on those being in ruby's default search path.
Readded, though honestly I'm not a fan of this reasoning. If its not in the Fedora / Ruby guidelines, it's not supported and thus we shouldn't add the additional complexity. Furthermore this approach would result in none of the paths ever changing, which obviously we don't want. Going forward we should identify only the paths that are supported and only include those.
We need not change these (i.e. paths) with the upgrade of 1.8.6.x -> 1.8.7.x. We just ensure that everything just go well with only ruby rpm (and its subpackages) upgraded from 1.8.6.x to 1.8.7.x without trouble.
And, anyway with ruby 1.9 (which currently kanarip is trying to package), there is a big big change.
Once again, I respectfully disagree with this, though with the goal of getting to 1.8.7 in as quickly as possible, I'll leave them in the package.
I disagree because I believe these directories being on the path is a pretty obvious mistake (eg the directory doesn't exist in the filesystem) and thus anyone using this directory is not conforming to Fedora/Ruby guidelines. I think its prudent that we fix the mistake ASAP so that additional software doesn't depend on this directory which will ultimately have to be removed from the path.
New SRPM uploaded:
Anyway I appreciate your contribution.
Regards, Mamoru
Not a problem, I'm working towards the next release taking your and Jim's feedback into account (also the newly released Ruby version), which should be out momentarily.
-Mo
Mohammed Morsi wrote: ....
Readded, though honestly I'm not a fan of this reasoning. If its not
....
Thanks.
I see you are still using this approach:
%build export LIB_PREFIX=%{_lib}
Using that approach causes the "make ...&& cd r*9/r*9&& make ..." idiom to subtly malfunction if it ends up running mkconfig.rb.
Done, changed it to use your patch.
Thanks.
New SRPM uploaded:
Minor suggestions:
- don't add two trailing blanks via ruby-1.8.7-lib-paths.patch You can remove just those two via e.g.,
perl -pi -e 's/(.) $/$1/' ruby-1.8.7-lib-paths.patch
- remove unused: %global sitedir2 %{ruby_sitelib}
- remove vestiges of emacs. Now that we don't distribute ruby-mode (it's in new-enough emacs), you can remove these lines from your spec:
# emacs sitelisp directory %{!?_emacs_sitelispdir: %global _emacs_sitelispdir %{_datadir}/emacs/site-lisp} %{!?_emacs_sitestartdir: %global _emacs_sitestartdir %{_datadir}/emacs/site-lisp/site-start.d}
BuildRequires: emacs
On 06/24/2010 12:58 AM, Jim Meyering wrote:
Mohammed Morsi wrote: ....
Readded, though honestly I'm not a fan of this reasoning. If its not
....
Thanks.
I see you are still using this approach:
%build export LIB_PREFIX=%{_lib}Using that approach causes the "make ...&& cd r*9/r*9&& make ..." idiom to subtly malfunction if it ends up running mkconfig.rb.
Done, changed it to use your patch.
Thanks.
New SRPM uploaded:
Minor suggestions:
don't add two trailing blanks via ruby-1.8.7-lib-paths.patch You can remove just those two via e.g.,
perl -pi -e 's/(.) $/$1/' ruby-1.8.7-lib-paths.patch
Actually only one of these whitespace changes is in this patch, the other one is in the always-use-i386 patch. Regardless, thanks for the catch, both have been fixed.
- remove unused: %global sitedir2 %{ruby_sitelib}
I had originally removed sitedir and sitedir2, but Mamoru asked me to readd them for compatibility purposes. Obviously they aren't used anymore in the spec file but I wasn't sure if the macros defined there are made available to other packages dependent on Ruby and thus readded them. If this is not the case, I agree, they should be removed.
http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/000138.html
- remove vestiges of emacs. Now that we don't distribute ruby-mode (it's in new-enough emacs), you can remove these lines from your spec:
# emacs sitelisp directory %{!?_emacs_sitelispdir: %global _emacs_sitelispdir %{_datadir}/emacs/site-lisp} %{!?_emacs_sitestartdir: %global _emacs_sitestartdir %{_datadir}/emacs/site-lisp/site-start.d}
BuildRequires: emacs
Removed.
New srpm, uploaded here:
http://mo.morsi.org/files/ruby-1.8.7.299-1.fc13.src.rpm
-Mo
Mohammed Morsi wrote: ...
Minor suggestions:
don't add two trailing blanks via ruby-1.8.7-lib-paths.patch You can remove just those two via e.g.,
perl -pi -e 's/(.) $/$1/' ruby-1.8.7-lib-paths.patch
Actually only one of these whitespace changes is in this patch, the other one is in the always-use-i386 patch. Regardless, thanks for the catch, both have been fixed.
Oh yeah, I did have to adjust two patches back when I first fixed those.
- remove unused: %global sitedir2 %{ruby_sitelib}
I had originally removed sitedir and sitedir2, but Mamoru asked me to
I now see that sitedir is also unused. Thanks for mentioning that. Hence it can go too. Not urgent, of course. AFAIK, if %{foo} is never used in the spec file (modulo %{... expression syntax), then there is no point in defining the corresponding %global.
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
New SRPM uploaded:
http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm
-Mo
By the way it seems 1.8.7p299 was released yesterday so please consider to upgrade.
Regards, Mamoru
Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
New SRPM uploaded: http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm
By the way it seems 1.8.7p299 was released yesterday so please consider to upgrade.
Thanks for the heads-up. Good timing. It appears that removing two patches is sufficient to adapt:
* remove patch30, aka ruby-1.8.7-openssl-1.0.patch; subsumed * remove patch101, aka ruby-1.8.7-rb_gc_guard_ptr-optimization.patch; subsumed
On 06/24/2010 01:48 PM, Jim Meyering wrote:
Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
New SRPM uploaded: http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm
By the way it seems 1.8.7p299 was released yesterday so please consider to upgrade.
Thanks for the heads-up. Good timing. It appears that removing two patches is sufficient to adapt:
- remove patch30, aka ruby-1.8.7-openssl-1.0.patch; subsumed
Are we absolutely sure we don't need this? Looking at the patch, yes it seems the changes to ossl.c and ossl_pkcs7.c made it into the upstream codebase, but the changes to ossl_ssl.c are still missing.
Ruby compiles fine, but I just don't want to omit something that fixes a critical bug or what not.
- remove patch101, aka ruby-1.8.7-rb_gc_guard_ptr-optimization.patch; subsumed
Agree on this one though, all these changes made it in upstream and thus this patch was removed (the patchset is looking nice and concise now).
The only things that I think are missing is readding the bits to pull in the tcltk branch for the ruby-tcltk package (if we still need this) and possibly an issue w/ Config::CONFIG['archdir'] being different than it is with 1.8.6. I verified that this is the only config value that is different (good test to add to the Ruby test suite), but am having some trouble compiling the rpm when I change it to match the value in 1.8.6, will this be an issue?
(BTW completely unrelated, but I'm out tommorow and most likely won't be available via email/irc, back on Monday)
-Mo
Mohammed Morsi wrote:
On 06/24/2010 01:48 PM, Jim Meyering wrote:
Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 06/24/2010 09:24 AM +9:00:
New SRPM uploaded: http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm
By the way it seems 1.8.7p299 was released yesterday so please consider to upgrade.
Thanks for the heads-up. Good timing. It appears that removing two patches is sufficient to adapt:
- remove patch30, aka ruby-1.8.7-openssl-1.0.patch; subsumed
Are we absolutely sure we don't need this? Looking at the patch, yes it seems the changes to ossl.c and ossl_pkcs7.c made it into the upstream codebase, but the changes to ossl_ssl.c are still missing.
Hi Mo,
Those change can only influence whether or how (with or without warnings) the code compiles. At least part of that patch is present in the new ossl.h, with this definition:
#if OPENSSL_VERSION_NUMBER >= 0x10000000L #define STACK _STACK #endif
the other change provided by that patch is
#if OPENSSL_VERSION_NUMBER >= 0x10000000L # define OSSL_MORE_CONST const #else # define OSSL_MORE_CONST #endif
[along with 3 uses of OSSL_MORE_CONST]
And since omitting that change does not cause a build failure we should be fine. At worst, it's required only when building against an older version of openssl than the one in F13.
Mohammed Morsi wrote, at 06/23/2010 04:09 AM +9:00:
On 06/22/2010 03:00 PM, Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 06:44 AM, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Thanks for the new version. I too am interested in this, and based on your work, have eliminated most of the complaints from rpmlint and made a few other improvements. Here are the first few changes that affect only your spec file:
summary: remove trailing blanks placate rpmlint ruby_* definitions: do not use trailing slashes in directory names _normalized_cpu: simplify definition
I integrated all these into the spec and bumped the version / rereleased it. It can be found here
Thanks. Not new, but just to confirm...
With your new path setup, I see this (from -2):
$ ruby -e 'puts $:' /usr/lib64/ruby/site_ruby/1.8.7 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8.7/x86_64-linux /usr/lib64/ruby/site_ruby /usr/lib/ruby/site_ruby/1.8.7 /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby /usr/lib64/ruby//1.8.7 /usr/lib64/ruby//1.8 /usr/lib64/ruby//1.8.7/x86_64-linux /usr/lib64/ruby/ /usr/lib/ruby//1.8.7 /usr/lib/ruby//1.8 /usr/lib/ruby/ .Even removing the 1.8.7 lines, trailing slashes and s,//,/, I still see differences with the reference, 1.8.6 path:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .I.e., with your 1.8.7, we'd now search /usr/lib/ruby/site_ruby/1.8 6th. With 1.8.6, we search it first.
Is this change deliberate?
I could be wrong, but I don't think the search path order matters so much here, since what goes into each of these dirs is pretty well defined and disparate. So long as all the required paths are there, whatever required modules will be loaded correctly.
If I'm wrong about this, someone please correct me. If I am, I believe this can be easily fixed by changing the order which they are pushed onto the include path in the ruby-1.8.7-lib-paths patch
In some cases ruby modules install ruby script and C extension module in the same name. - e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs * gnome2.rb under /usr/lib/ruby/site_ruby/1.8/ * gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/ In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm) ------------------------------------------------------- [tasaka1@localhost ~]$ ruby -e 'require "gnome2"' [tasaka1@localhost ~]$ ------------------------------------------------------- ... no problem. However if we change the order of search path so that /usr/lib/ruby/site_ruby/1.8/i386-linux/ is to be searched first: ------------------------------------------------------- [tasaka1@localhost ~]$ export RUBYLIB=/usr/lib/ruby/site_ruby/1.8/i386-linux/ [tasaka1@localhost ~]$ ruby -e "require 'gnome2'" /usr/lib/ruby/site_ruby/1.8/i386-linux/gnome2.so: /usr/lib/ruby/site_ruby/1.8/i386-linux/gnome2.so: undefined symbol: rbgutil_id_module_eval - /usr/lib/ruby/site_ruby/1.8/i386-linux/gnome2.so (LoadError) from -e:1 ------------------------------------------------------- so this causes error. So /usr/lib/ruby/site_ruby/1.8/ must be searched before /usr/lib/ruby/site_ruby/1.8/i386-linux/.
Also with your srpm /usr/lib/ruby/site_ruby/1.8/i386-linux/ does not seem to be searched (I see only 1.8.7, not 1.8). This causes problems with the binary rpms which already installs C extension modules under /usr/lib/ruby/site_ruby/1.8/i386-linux/. We should ensure that we can upgrade 1.8.6.x ruby rpms to 1.8.7.x ones without recompiling other ruby related rpms.
Regards, Mamoru
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs
- gnome2.rb under /usr/lib/ruby/site_ruby/1.8/
- gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Jim Meyering wrote, at 06/23/2010 07:31 PM +9:00:
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs
- gnome2.rb under /usr/lib/ruby/site_ruby/1.8/
- gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Currently at: http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/
(I have not moved these rpms to somewhere else than koji server yet)
Mamoru
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 07:31 PM +9:00:
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs
- gnome2.rb under /usr/lib/ruby/site_ruby/1.8/
- gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Currently at: http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/
Thank you. I have begun reviewing it. I have adopted the changes that split some of the longer-than-80 lines.
So far I have one suggestion: do not add a duplicate definition: (you can see the other, existing one at the end, in the context)
From 5416c79435bc17322a39f65997fdedbfdb30e21b Mon Sep 17 00:00:00 2001
From: Jim Meyering meyering@redhat.com Date: Wed, 23 Jun 2010 17:52:57 +0200 Subject: [PATCH] do not add duplicate definition of RUBY_LIB_PATH in patch
ruby-1.8.7-p249-rubyprefix.patch: Remove duplicate definition: RUBY_LIB_PATH="${RUBY_LIB_PREFIX}/${MAJOR}.${MINOR}" --- RHEL-6/ruby-1.8.7-p249-rubyprefix.patch | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/RHEL-6/ruby-1.8.7-p249-rubyprefix.patch b/RHEL-6/ruby-1.8.7-p249-rubyprefix.patch index b977b51..faf31e5 100644 --- a/RHEL-6/ruby-1.8.7-p249-rubyprefix.patch +++ b/RHEL-6/ruby-1.8.7-p249-rubyprefix.patch @@ -2,45 +2,45 @@ +++ ruby-1.8.7-p249/configure.in 2010-06-17 01:18:18.000000000 +0900 @@ -1706,6 +1706,13 @@ ri_suffix=$program_suffix
RUBY_INSTALL_NAME="${ri_prefix}ruby${ri_suffix}" + +AC_ARG_WITH(ruby-prefix, + AC_HELP_STRING([--with-ruby-prefix], [build ruby with the special library prefix.]), + [with_ruby_prefix="$withval"], + [with_ruby_prefix=""]) + +if test "x$with_ruby_prefix" = "x"; then case "$target_os" in cygwin*|mingw*) RUBYW_INSTALL_NAME="${ri_prefix}rubyw${ri_suffix}" @@ -1713,12 +1720,20 @@ ;; esac RUBY_LIB_PREFIX=`eval echo \"${libdir}/ruby\"` +else + RUBY_LIB_PREFIX="${with_ruby_prefix}/ruby" +fi -+RUBY_LIB_PATH="${RUBY_LIB_PREFIX}/${MAJOR}.${MINOR}" ++ +RUBY_LIB_PATH2="${libdir}/ruby/${MAJOR}.${MINOR}"
AC_ARG_WITH(sitedir, [ --with-sitedir=DIR site libraries in DIR [[LIBDIR/ruby/site_ruby]]], [sitedir=$withval], [sitedir='${libdir}/ruby/site_ruby']) -SITE_DIR=`eval echo \"${sitedir}\"` +SITE_DIR=`eval echo \"${sitedir}\" | sed -e "s/lib64/lib/"` +_fc_sitedir="${sitedir}" +SITE_DIR2=`eval echo \"${_fc_sitedir}\"` +sitedir=`eval echo \"${sitedir}\" | sed -e "s/lib64/lib/"`
case "$target_os" in cygwin*|mingw*|*djgpp*|os2-emx*) @@ -1728,9 +1743,11 @@ *) RUBY_LIB_PREFIX="`eval echo \"$RUBY_LIB_PREFIX\" | sed 's|^NONE/|'"$prefix"'/|'`" RUBY_SITE_LIB_PATH="`eval echo \"$SITE_DIR\" | sed 's|^NONE/|'"$prefix"'/|'`" + RUBY_SITE_LIB_PATH2="$SITE_DIR2" ;; esac RUBY_LIB_PATH="${RUBY_LIB_PREFIX}/${MAJOR}.${MINOR}"
Jim Meyering wrote:
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 07:31 PM +9:00:
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs
- gnome2.rb under /usr/lib/ruby/site_ruby/1.8/
- gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Currently at: http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/
Thank you. I have begun reviewing it. I have adopted the changes that split some of the longer-than-80 lines.
I built from your srpm, and ran this in the build directory on an x86_64 system:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:' /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib64/ruby/vendor_ruby/1.8 /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux /usr/lib64/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .
Is that the path you intend? Based on what you said, I expected it to match the path of 1.8.6.x:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .
Actually, it looks fine, as long as the addition of the three new vendor_ruby/* directories is desired.
Sorry now I am fixing up other packages, however:
Jim Meyering wrote, at 06/24/2010 01:40 AM +9:00:
Jim Meyering wrote:
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 07:31 PM +9:00:
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs
- gnome2.rb under /usr/lib/ruby/site_ruby/1.8/
- gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Currently at: http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/
Thank you. I have begun reviewing it. I have adopted the changes that split some of the longer-than-80 lines.
(and I just note that I prefer to write one (Build)Requires on each line because it is easier to read, especially when (Build)Requires changed)
I built from your srpm, and ran this in the build directory on an x86_64 system:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:' /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib64/ruby/vendor_ruby/1.8 /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux /usr/lib64/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .
Is that the path you intend? Based on what you said, I expected it to match the path of 1.8.6.x:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .
Actually, it looks fine, as long as the addition of the three new vendor_ruby/* directories is desired.
Well, while I don't use vendor_ruby now (and with the transition from 1.8.6.x to 1.8.7.x on Fedora perhaps this is not needed), actually this is the upstream change:
from ruby_1_8_7/NEWS: ------------------------------------------------------------------- 19 == Changes since the 1.8.6 release 20 21 === Configuration changes 22 23 * vendor_ruby directory 24 25 A new library directory named `vendor_ruby' is introduced in 26 addition to `site_ruby'. The idea is to separate libraries 27 installed by the package system (`vendor') from manually (`site') 28 installed libraries preventing the former from getting overwritten 29 by the latter, while preserving the user option to override vendor 30 libraries with site libraries. (`site_ruby' takes precedence over 31 `vendor_ruby') 32 33 If you are a package maintainer, make each library package configure 34 the library passing the `--vendor' option to `extconf.rb' so that 35 the library files will get installed under `vendor_ruby'. 36 37 You can change the directory locations using configure options such 38 as `--with-sitedir=DIR' and `--with-vendordir=DIR'. ------------------------------------------------------------------- So as this is the explicit upstream change, I want to keep this.
Regards, Mamoru
On 06/23/2010 01:13 PM, Mamoru Tasaka wrote:
Sorry now I am fixing up other packages, however:
Jim Meyering wrote, at 06/24/2010 01:40 AM +9:00:
Jim Meyering wrote:
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 07:31 PM +9:00:
Mamoru Tasaka wrote: ...
In some cases ruby modules install ruby script and C extension module in the same name.
- e.g. On i686 ruby-gnome2-0.19.4-2.fc14.i686 installs * gnome2.rb under /usr/lib/ruby/site_ruby/1.8/ * gnome2.so under /usr/lib/ruby/site_ruby/1.8/i386-linux/
In this case, with current 1.8.6.x ruby srpm (and also my 1.8.7.x srpm)
Would you please point me to your latest 1.8.7.x srpm ?
Currently at: http://koji.fedoraproject.org/scratch/mtasaka/task_2258338/
Thank you. I have begun reviewing it. I have adopted the changes that split some of the longer-than-80 lines.
(and I just note that I prefer to write one (Build)Requires on each line because it is easier to read, especially when (Build)Requires changed)
Agreed.
I built from your srpm, and ran this in the build directory on an x86_64 system:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:' /usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib64/ruby/vendor_ruby/1.8 /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux /usr/lib64/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .Is that the path you intend? Based on what you said, I expected it to match the path of 1.8.6.x:
/usr/lib/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/x86_64-linux /usr/lib/ruby/site_ruby /usr/lib64/ruby/site_ruby /usr/lib64/site_ruby/1.8 /usr/lib64/site_ruby/1.8/x86_64-linux /usr/lib64/site_ruby /usr/lib/ruby/1.8 /usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8/x86_64-linux .Actually, it looks fine, as long as the addition of the three new vendor_ruby/* directories is desired.
The new 1.8.7 search path as provided by my rpm is as follows:
1. /usr/lib/ruby/site_ruby/1.8 2. /usr/lib64/ruby/site_ruby/1.8 3. /usr/lib64/ruby/site_ruby/1.8/x86_64-linux 4. /usr/lib/ruby/site_ruby 5. /usr/lib64/ruby/site_ruby 6. /usr/lib/ruby/1.8 7. /usr/lib64/ruby/1.8 8. /usr/lib64/ruby/1.8/x86_64-linux
As noted before, /usr/lib64/site_ruby subdirs were removed as the Ruby 1.8.6 package doesn't provide that dir
Well, while I don't use vendor_ruby now (and with the transition from 1.8.6.x to 1.8.7.x on Fedora perhaps this is not needed), actually this is the upstream change:
from ruby_1_8_7/NEWS:
19 == Changes since the 1.8.6 release 20 21 === Configuration changes 22 23 * vendor_ruby directory 24 25 A new library directory named `vendor_ruby' is introduced in 26 addition to `site_ruby'. The idea is to separate libraries 27 installed by the package system (`vendor') from manually (`site') 28 installed libraries preventing the former from getting overwritten 29 by the latter, while preserving the user option to override vendor 30 libraries with site libraries. (`site_ruby' takes precedence over 31 `vendor_ruby') 32 33 If you are a package maintainer, make each library package configure 34 the library passing the `--vendor' option to `extconf.rb' so that 35 the library files will get installed under `vendor_ruby'. 36 37 You can change the directory locations using configure options such 38 as `--with-sitedir=DIR' and `--with-vendordir=DIR'.
So as this is the explicit upstream change, I want to keep this.
Regards, Mamoru
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I make use of the --with-vendordir flag in my ruby 1.8.7 specfile so we should be good to go. Is there anything else you need me to merge into mine? (either from your 1.8.7 srpm/spec, upstream, or something I removed by mistake?)
-Mo
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
(There might be a macro more suitable for this than %_libdir)
David
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORM
Using an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1
But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1
# Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORMUsing an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
-Mo
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORMUsing an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORMUsing an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
FYI, I've confirmed that this works for me:
commit 8cc2823aec419d282dfe3a1b62ed46e7453adbed Author: Jim Meyering meyering@redhat.com Date: Tue Jun 22 22:15:59 2010 +0200
remove mkconfig.rb-modifying patch(#23) altogether
- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying code in %install. - ruby-multilib.patch: Remove file.
diff --git a/RHEL-6/ruby.spec b/RHEL-6/ruby.spec index 00e7c50..ad0c7db 100644 --- a/RHEL-6/ruby.spec +++ b/RHEL-6/ruby.spec @@ -25,7 +25,7 @@
Name: ruby Version: %{rubyver}%{?dotpatchlevel} -Release: 2%{?dist} +Release: 3%{?dist} License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -53,8 +53,6 @@ Source4: irb.1 # http://lists.fedoraproject.org/pipermail/ruby-sig/2010-May/000096.html Source100: ruby-1.8-rev%{tk_using_svn_number}_trunk-ext_tk.tar.gz
-# Patch23 is Fedora specific -Patch23: ruby-multilib.patch # Patch27 is not in the upstream VCS. # This patch, while not technically required in the context of Rails, # does seem like a useful addition: improved safety/compatibility: @@ -193,7 +191,6 @@ pushd %{name}-%{arcver} find tk -type d -name .svn | sort -r | xargs rm -rf )
-%patch23 -p1 %patch27 -p0 %patch29 -p1 %patch30 -p1 @@ -360,6 +357,24 @@ popd # done cd ..
+# Change /lib/ruby/ to /lib64/ruby/ on a 64-bit system +if test %{_lib} != lib; then + d=$RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} + t=$d/mkconfig.rb + # ruby-1.9.2 has this line in tool/mkconfig.rb: + # prefix = "/lib/ruby/#{version}/#{arch}" + # while ruby-1.8.7 has this in mkconfig.rb: + # prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM + # The following covers both: + test -f $t || t=$d/tool/mkconfig.rb + if grep '^prefix = ./lib/ruby/' $t; then + sed -i 's,^(prefix = .)/lib/ruby/,\1%{_lib}/ruby/,' $t || exit 1 + else + echo "unexpected content in $t" + exit 1 + fi +fi + # installing binaries ... make -C $RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} DESTDIR=$RPM_BUILD_ROOT install
@@ -546,6 +561,11 @@ rm -rf $RPM_BUILD_ROOT %doc tmp-ruby-docs/ruby-libs/*
%changelog +* Tue Jun 22 2010 Jim Meyering meyering@redhat.com - 1.8.7.249-3 +- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying + code in %install. +- ruby-multilib.patch: Remove file. + * Tue Jun 22 2010 Jim Meyering meyering@redhat.com - 1.8.7.249-2 - Integrate addition of patch101 by Mohammed Morsi. This fixes the segv-inducing marshaling bug affecting rails-3.0.0.
The above isn't quite accurate. You need this additional change (to the %changelog text!) in order to avoid a cryptic "Package already exists: %package debuginfo" error from rpmbuild:
- code in %install. + code in "install", above.
I guess that's rpmbuild's way of saying you must not refer to "%install" in a %changelog entry.
Jim Meyering wrote, at 06/23/2010 06:03 AM +9:00:
Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
> I added this patch to my specfile as well, bumped the release, and > updated the changelog to include your feedback. > Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endifThat patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORMUsing an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
FYI, I've confirmed that this works for me:
commit 8cc2823aec419d282dfe3a1b62ed46e7453adbed Author: Jim Meyeringmeyering@redhat.com Date: Tue Jun 22 22:15:59 2010 +0200
remove mkconfig.rb-modifying patch(#23) altogether - Remove patch 23 altogether. Replace it with mkconfig.rb-modifying code in %install. - ruby-multilib.patch: Remove file.diff --git a/RHEL-6/ruby.spec b/RHEL-6/ruby.spec index 00e7c50..ad0c7db 100644 --- a/RHEL-6/ruby.spec +++ b/RHEL-6/ruby.spec @@ -25,7 +25,7 @@
Name: ruby Version: %{rubyver}%{?dotpatchlevel} -Release: 2%{?dist} +Release: 3%{?dist} License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -53,8 +53,6 @@ Source4: irb.1 # http://lists.fedoraproject.org/pipermail/ruby-sig/2010-May/000096.html Source100: ruby-1.8-rev%{tk_using_svn_number}_trunk-ext_tk.tar.gz
-# Patch23 is Fedora specific -Patch23: ruby-multilib.patch # Patch27 is not in the upstream VCS. # This patch, while not technically required in the context of Rails, # does seem like a useful addition: improved safety/compatibility: @@ -193,7 +191,6 @@ pushd %{name}-%{arcver} find tk -type d -name .svn | sort -r | xargs rm -rf )
-%patch23 -p1 %patch27 -p0 %patch29 -p1 %patch30 -p1 @@ -360,6 +357,24 @@ popd # done cd ..
+# Change /lib/ruby/ to /lib64/ruby/ on a 64-bit system +if test %{_lib} != lib; then
- d=$RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver}
- t=$d/mkconfig.rb
- # ruby-1.9.2 has this line in tool/mkconfig.rb:
- # prefix = "/lib/ruby/#{version}/#{arch}"
- # while ruby-1.8.7 has this in mkconfig.rb:
- # prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
- # The following covers both:
- test -f $t || t=$d/tool/mkconfig.rb
- if grep '^prefix = ./lib/ruby/' $t; then
sed -i 's,^\(prefix = .\)/lib/ruby/,\1%{_lib}/ruby/,' $t || exit 1- else
echo "unexpected content in $t"exit 1- fi
+fi
- # installing binaries ... make -C $RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} DESTDIR=$RPM_BUILD_ROOT install
@@ -546,6 +561,11 @@ rm -rf $RPM_BUILD_ROOT %doc tmp-ruby-docs/ruby-libs/*
%changelog +* Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-3 +- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying
- code in %install.
+- ruby-multilib.patch: Remove file.
- Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-2
- Integrate addition of patch101 by Mohammed Morsi. This fixes the segv-inducing marshaling bug affecting rails-3.0.0.
The above isn't quite accurate. You need this additional change (to the %changelog text!) in order to avoid a cryptic "Package already exists: %package debuginfo" error from rpmbuild:
- code in %install.
- code in "install", above.
I guess that's rpmbuild's way of saying you must not refer to "%install" in a %changelog entry.
Please avoid to use such comprecated sed craft. While I use sed craft so many times, this type of craft makes it difficult for other persons to understand what these lines are for. If comprecated sed craft is needed, creating a patch is much appreciated.
Regards, Mamoru
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 06:03 AM +9:00:
Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
> Mohammed Morsi wrote: > >> I added this patch to my specfile as well, bumped the release, and >> updated the changelog to include your feedback. >> > Hi again, > > rpmlint complains about this conditionally-applied patch: > > %ifarch ppc64 s390x sparc64 x86_64 > %patch23 -p1 > %endif > > That patch (ruby-1.8.7-multilib.patch) is small enough that > I'll include it here, for reference: > > --- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 > +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 > @@ -102,7 +102,7 @@ > > drive = File::PATH_SEPARATOR == ';' > > -prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM > +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM > > It is easy to perform the same task using an unconditional patch, > so I wrote this replacement: > Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORMUsing an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
FYI, I've confirmed that this works for me:
commit 8cc2823aec419d282dfe3a1b62ed46e7453adbed Author: Jim Meyeringmeyering@redhat.com Date: Tue Jun 22 22:15:59 2010 +0200
remove mkconfig.rb-modifying patch(#23) altogether - Remove patch 23 altogether. Replace it with mkconfig.rb-modifying code in %install. - ruby-multilib.patch: Remove file.diff --git a/RHEL-6/ruby.spec b/RHEL-6/ruby.spec index 00e7c50..ad0c7db 100644 --- a/RHEL-6/ruby.spec +++ b/RHEL-6/ruby.spec @@ -25,7 +25,7 @@
Name: ruby Version: %{rubyver}%{?dotpatchlevel} -Release: 2%{?dist} +Release: 3%{?dist} License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -53,8 +53,6 @@ Source4: irb.1 # http://lists.fedoraproject.org/pipermail/ruby-sig/2010-May/000096.html Source100: ruby-1.8-rev%{tk_using_svn_number}_trunk-ext_tk.tar.gz
-# Patch23 is Fedora specific -Patch23: ruby-multilib.patch # Patch27 is not in the upstream VCS. # This patch, while not technically required in the context of Rails, # does seem like a useful addition: improved safety/compatibility: @@ -193,7 +191,6 @@ pushd %{name}-%{arcver} find tk -type d -name .svn | sort -r | xargs rm -rf )
-%patch23 -p1 %patch27 -p0 %patch29 -p1 %patch30 -p1 @@ -360,6 +357,24 @@ popd # done cd ..
+# Change /lib/ruby/ to /lib64/ruby/ on a 64-bit system +if test %{_lib} != lib; then
- d=$RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver}
- t=$d/mkconfig.rb
- # ruby-1.9.2 has this line in tool/mkconfig.rb:
- # prefix = "/lib/ruby/#{version}/#{arch}"
- # while ruby-1.8.7 has this in mkconfig.rb:
- # prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
- # The following covers both:
- test -f $t || t=$d/tool/mkconfig.rb
- if grep '^prefix = ./lib/ruby/' $t; then
sed -i 's,^\(prefix = .\)/lib/ruby/,\1%{_lib}/ruby/,' $t || exit 1- else
echo "unexpected content in $t"exit 1- fi
+fi
- # installing binaries ... make -C $RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} DESTDIR=$RPM_BUILD_ROOT install
@@ -546,6 +561,11 @@ rm -rf $RPM_BUILD_ROOT %doc tmp-ruby-docs/ruby-libs/*
%changelog +* Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-3 +- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying
- code in %install.
+- ruby-multilib.patch: Remove file.
- Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-2
- Integrate addition of patch101 by Mohammed Morsi. This fixes the segv-inducing marshaling bug affecting rails-3.0.0.
The above isn't quite accurate. You need this additional change (to the %changelog text!) in order to avoid a cryptic "Package already exists: %package debuginfo" error from rpmbuild:
- code in %install.
- code in "install", above.
I guess that's rpmbuild's way of saying you must not refer to "%install" in a %changelog entry.
Please avoid to use such comprecated sed craft. While I use sed craft so many times, this type of craft makes it difficult for other persons to understand what these lines are for.
That is why I added nearly as many lines of comment as of code. Considering the size of the existing %install section and its code/comment ratio, I'm surprised that you think my addition would be difficult to understand.
If understanding is the only issue, let me know if adding more comments would help.
If comprecated sed craft is needed, creating a patch is much appreciated.
I presume you would prefer a patch, so I am discarding the above, leaving the patch I used before. I cannot take David Lutterkort's suggestion to use the likes of %{_lib} without adding shell code (or fragile envvar settings) to %install.
FYI, here is my ruby-multilib.patch (patch23):
diff -ruN ruby-1.8.3.orig/mkconfig.rb ruby-1.8.3/mkconfig.rb --- ruby-1.8.7/mkconfig.rb 2008-06-06 12:39:57.000000000 +0200 +++ ruby-1.8.7/mkconfig.rb 2010-06-21 11:17:13.839498249 +0200 @@ -39,6 +39,7 @@ vars = {} has_version = false continued_name = nil continued_line = nil +lib_64 = '' File.foreach "config.status" do |line| next if /^#/ =~ line name = nil @@ -96,13 +97,21 @@ File.foreach "config.status" do |line| v_others << v end has_version = true if name == "MAJOR" + + # If the target architecture is one of the following, + # ppc64 s390x sparc64 x86_64 + # then use "lib64", not "lib" in prefix. + if name == "target_cpu" and (/64"$/ =~ val or val == '"s390x"') + lib_64 = '64' + end end # break if /^CEOF/ end
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = "/lib#{lib_64}/ruby/" \ + + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM print " TOPDIR = File.dirname(__FILE__).chomp!(#{prefix.dump})\n" print " DESTDIR = ", (drive ? "TOPDIR && TOPDIR[/\A[a-z]:/i] || " : ""), "'' unless defined? DESTDIR\n" print " CONFIG = {}\n"
Jim Meyering wrote, at 06/23/2010 04:12 PM +9:00:
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 06:03 AM +9:00:
Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote:
David Lutterkort wrote:
> On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote: > >> Mohammed Morsi wrote: >> >>> I added this patch to my specfile as well, bumped the release, and >>> updated the changelog to include your feedback. >>> >> Hi again, >> >> rpmlint complains about this conditionally-applied patch: >> >> %ifarch ppc64 s390x sparc64 x86_64 >> %patch23 -p1 >> %endif >> >> That patch (ruby-1.8.7-multilib.patch) is small enough that >> I'll include it here, for reference: >> >> --- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 >> +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 >> @@ -102,7 +102,7 @@ >> >> drive = File::PATH_SEPARATOR == ';' >> >> -prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM >> +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM >> >> It is easy to perform the same task using an unconditional patch, >> so I wrote this replacement: >> > Couldn't we just get the right value from the environment ? I haven't > looked if it's already in one of the standard env vars that rpmbuild > sets up, but if bad comes to worst, couldn't we just do 'export > LIB_PREFIX=%{_libdir}' in the spec file and then > > prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM > Using an rpm variable like that is more maintainable than enumerating 64-bit architectures or even using a regexp like /64$/ like I did. However, while it would work when building via rpm tools, if someone ever builds manually, they would have to know to set that envvar -- too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
However, we can do something similar that might be more robust: run something like this from the spec file:
sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1But that is fragile in its own way. If mkconfig.rb changes, the sed regexp may fail to match or it may match in some new place, introducing an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
We could mitigate that risk by adding tests that would fail if our preconditions stop being met:
# Ensure that the "sed" command below does the right thing. grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 test $(grep -c '/lib/ruby/') = 1 || exit 1 # Use /lib64/ruby/ on a 64-bit system. sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
FYI, I've confirmed that this works for me:
commit 8cc2823aec419d282dfe3a1b62ed46e7453adbed Author: Jim Meyeringmeyering@redhat.com Date: Tue Jun 22 22:15:59 2010 +0200
remove mkconfig.rb-modifying patch(#23) altogether - Remove patch 23 altogether. Replace it with mkconfig.rb-modifying code in %install. - ruby-multilib.patch: Remove file.diff --git a/RHEL-6/ruby.spec b/RHEL-6/ruby.spec index 00e7c50..ad0c7db 100644 --- a/RHEL-6/ruby.spec +++ b/RHEL-6/ruby.spec @@ -25,7 +25,7 @@
Name: ruby Version: %{rubyver}%{?dotpatchlevel} -Release: 2%{?dist} +Release: 3%{?dist} License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -53,8 +53,6 @@ Source4: irb.1 # http://lists.fedoraproject.org/pipermail/ruby-sig/2010-May/000096.html Source100: ruby-1.8-rev%{tk_using_svn_number}_trunk-ext_tk.tar.gz
-# Patch23 is Fedora specific -Patch23: ruby-multilib.patch # Patch27 is not in the upstream VCS. # This patch, while not technically required in the context of Rails, # does seem like a useful addition: improved safety/compatibility: @@ -193,7 +191,6 @@ pushd %{name}-%{arcver} find tk -type d -name .svn | sort -r | xargs rm -rf )
-%patch23 -p1 %patch27 -p0 %patch29 -p1 %patch30 -p1 @@ -360,6 +357,24 @@ popd # done cd ..
+# Change /lib/ruby/ to /lib64/ruby/ on a 64-bit system +if test %{_lib} != lib; then
- d=$RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver}
- t=$d/mkconfig.rb
- # ruby-1.9.2 has this line in tool/mkconfig.rb:
- # prefix = "/lib/ruby/#{version}/#{arch}"
- # while ruby-1.8.7 has this in mkconfig.rb:
- # prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
- # The following covers both:
- test -f $t || t=$d/tool/mkconfig.rb
- if grep '^prefix = ./lib/ruby/' $t; then
sed -i 's,^\(prefix = .\)/lib/ruby/,\1%{_lib}/ruby/,' $t || exit 1- else
echo "unexpected content in $t"exit 1- fi
+fi
- # installing binaries ... make -C $RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} DESTDIR=$RPM_BUILD_ROOT install
@@ -546,6 +561,11 @@ rm -rf $RPM_BUILD_ROOT %doc tmp-ruby-docs/ruby-libs/*
%changelog +* Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-3 +- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying
- code in %install.
+- ruby-multilib.patch: Remove file.
- Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-2
- Integrate addition of patch101 by Mohammed Morsi. This fixes the segv-inducing marshaling bug affecting rails-3.0.0.
The above isn't quite accurate. You need this additional change (to the %changelog text!) in order to avoid a cryptic "Package already exists: %package debuginfo" error from rpmbuild:
- code in %install.
- code in "install", above.
I guess that's rpmbuild's way of saying you must not refer to "%install" in a %changelog entry.
Please avoid to use such comprecated sed craft. While I use sed craft so many times, this type of craft makes it difficult for other persons to understand what these lines are for.
That is why I added nearly as many lines of comment as of code. Considering the size of the existing %install section and its code/comment ratio, I'm surprised that you think my addition would be difficult to understand.
Actually as I was the "Merge review" reviewer of ruby.spec I already consider that %install section is already so complecated (especially for handling documents to be installed, fixing encoding, shebang,....) and once switching from 1.8.6.x to 1.8.7.x is done, I really consider to clean up %install section (if time allows). With using ruby_1_8/ext/tk head, I had to modify %install section a bit, but I took some time to understand what part of %install I had to modify....
If understanding is the only issue, let me know if adding more comments would help.
If comprecated sed craft is needed, creating a patch is much appreciated.
I presume you would prefer a patch, so I am discarding the above, leaving the patch I used before. I cannot take David Lutterkort's suggestion to use the likes of %{_lib} without adding shell code (or fragile envvar settings) to %install.
FYI, here is my ruby-multilib.patch (patch23):
diff -ruN ruby-1.8.3.orig/mkconfig.rb ruby-1.8.3/mkconfig.rb --- ruby-1.8.7/mkconfig.rb 2008-06-06 12:39:57.000000000 +0200 +++ ruby-1.8.7/mkconfig.rb 2010-06-21 11:17:13.839498249 +0200 @@ -39,6 +39,7 @@ vars = {} has_version = false continued_name = nil continued_line = nil +lib_64 = '' File.foreach "config.status" do |line| next if /^#/ =~ line name = nil @@ -96,13 +97,21 @@ File.foreach "config.status" do |line| v_others<< v end has_version = true if name == "MAJOR"
# If the target architecture is one of the following,
# ppc64 s390x sparc64 x86_64
# then use "lib64", not "lib" in prefix.
if name == "target_cpu" and (/64"$/ =~ val or val == '"s390x"')
lib_64 = '64'end end # break if /^CEOF/ end
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = "/lib#{lib_64}/ruby/" \
print " TOPDIR = File.dirname(__FILE__).chomp!(#{prefix.dump})\n" print " DESTDIR = ", (drive ? "TOPDIR&& TOPDIR[/\A[a-z]:/i] || " : ""), "'' unless defined? DESTDIR\n" print " CONFIG = {}\n"
- RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
I think %ifarch <64 bit architecture> <apply patches specific to 64 bit> %endif is preferable because - it clearly shows what special treatment should be done on x86_64 or so - can avoid unneeded codes in 32 bit architecture - and avoid to increase the size of the needed patch (or sed craft) unneededly. If we use %ifarch..., encoding "if name == "target_cpu"...... or so handling in installed codes is unneeded.
Adding 32 bit <-> 64 bit handling in the installed codes is redundant unless we support 32 bit <-> 64 bit ruby parallel install or so. Avoiding %ifarch .... %endif just because "rpmlint complaints" is questionable.
Regards, Mamoru
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 04:12 PM +9:00:
Mamoru Tasaka wrote:
Jim Meyering wrote, at 06/23/2010 06:03 AM +9:00:
Jim Meyering wrote:
Mohammed Morsi wrote:
On 06/22/2010 01:26 PM, Jim Meyering wrote: > David Lutterkort wrote: > >> On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote: >> >>> Mohammed Morsi wrote: >>> >>>> I added this patch to my specfile as well, bumped the release, and >>>> updated the changelog to include your feedback. >>>> >>> Hi again, >>> >>> rpmlint complains about this conditionally-applied patch: >>> >>> %ifarch ppc64 s390x sparc64 x86_64 >>> %patch23 -p1 >>> %endif >>> >>> That patch (ruby-1.8.7-multilib.patch) is small enough that >>> I'll include it here, for reference: >>> >>> --- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 >>> +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 >>> @@ -102,7 +102,7 @@ >>> >>> drive = File::PATH_SEPARATOR == ';' >>> >>> -prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM >>> +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM >>> >>> It is easy to perform the same task using an unconditional patch, >>> so I wrote this replacement: >>> >> Couldn't we just get the right value from the environment ? I haven't >> looked if it's already in one of the standard env vars that rpmbuild >> sets up, but if bad comes to worst, couldn't we just do 'export >> LIB_PREFIX=%{_libdir}' in the spec file and then >> >> prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM >> > Using an rpm variable like that is more maintainable than enumerating > 64-bit architectures or even using a regexp like /64$/ like I did. > However, while it would work when building via rpm tools, if someone > ever builds manually, they would have to know to set that envvar -- > too easily missed or forgotten.
How would anyone go about building this manually with this change included? AFAIK since this change is only in the patch that is pulled in via the spec / rpmbuild, the only way that it will appear is if someone is building ruby using the rpm tools.
Hi Mo,
I've seen it documented to run e.g., "make prep" for a project and then cd into the directory that creates and "develop" (i.e., run make, etc.). This is not a hypothetical case.
> However, we can do something similar that might be more robust: > run something like this from the spec file: > > sed -i 's,/lib/ruby/,%{_whatever}/,' .../mkconfig.rb || exit 1 > > But that is fragile in its own way. If mkconfig.rb changes, the sed > regexp may fail to match or it may match in some new place, introducing > an unwanted change.
Agreed, this global sed will most likely cause headaches in the future.
If you're so concerned, and don't like the insurance below, it's easy to make the sed regexp more specific. The line it's modifying is long and unlikely to change frequently.
> We could mitigate that risk by adding tests > that would fail if our preconditions stop being met: > > # Ensure that the "sed" command below does the right thing. > grep 'prefix = ./lib/ruby/. + RUBY_VERSION.sub' || exit 1 > test $(grep -c '/lib/ruby/') = 1 || exit 1 > > # Use /lib64/ruby/ on a 64-bit system. > sed -i 's,/lib/ruby/,%{_whatever}/,' mkconfig.rb || exit 1
This will also lead to more maintenance as if either of those conditions become true and cause rpmbuild to exit, we will need to figure out an alternative solution to this problem.
That's the whole idea of this approach. In the unlikely event that something important changes, you absolutely do want to be forced to get involved. You'd get an rpmbuild failure that has to be investigated, rather than a silent change in behavior that someone would have to debug farther away from the source.
It is for the same reason that patches are applied using the most strict setting, allowing no "fuzz".
FYI, I've confirmed that this works for me:
commit 8cc2823aec419d282dfe3a1b62ed46e7453adbed Author: Jim Meyeringmeyering@redhat.com Date: Tue Jun 22 22:15:59 2010 +0200
remove mkconfig.rb-modifying patch(#23) altogether - Remove patch 23 altogether. Replace it with mkconfig.rb-modifying code in %install. - ruby-multilib.patch: Remove file.diff --git a/RHEL-6/ruby.spec b/RHEL-6/ruby.spec index 00e7c50..ad0c7db 100644 --- a/RHEL-6/ruby.spec +++ b/RHEL-6/ruby.spec @@ -25,7 +25,7 @@
Name: ruby Version: %{rubyver}%{?dotpatchlevel} -Release: 2%{?dist} +Release: 3%{?dist} License: Ruby or GPLv2 URL: http://www.ruby-lang.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -53,8 +53,6 @@ Source4: irb.1 # http://lists.fedoraproject.org/pipermail/ruby-sig/2010-May/000096.html Source100: ruby-1.8-rev%{tk_using_svn_number}_trunk-ext_tk.tar.gz
-# Patch23 is Fedora specific -Patch23: ruby-multilib.patch # Patch27 is not in the upstream VCS. # This patch, while not technically required in the context of Rails, # does seem like a useful addition: improved safety/compatibility: @@ -193,7 +191,6 @@ pushd %{name}-%{arcver} find tk -type d -name .svn | sort -r | xargs rm -rf )
-%patch23 -p1 %patch27 -p0 %patch29 -p1 %patch30 -p1 @@ -360,6 +357,24 @@ popd # done cd ..
+# Change /lib/ruby/ to /lib64/ruby/ on a 64-bit system +if test %{_lib} != lib; then
- d=$RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver}
- t=$d/mkconfig.rb
- # ruby-1.9.2 has this line in tool/mkconfig.rb:
- # prefix = "/lib/ruby/#{version}/#{arch}"
- # while ruby-1.8.7 has this in mkconfig.rb:
- # prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
- # The following covers both:
- test -f $t || t=$d/tool/mkconfig.rb
- if grep '^prefix = ./lib/ruby/' $t; then
sed -i 's,^\(prefix = .\)/lib/ruby/,\1%{_lib}/ruby/,' $t || exit 1- else
echo "unexpected content in $t"exit 1- fi
+fi
- # installing binaries ... make -C $RPM_BUILD_DIR/%{name}-%{version}/%{name}-%{arcver} DESTDIR=$RPM_BUILD_ROOT install
@@ -546,6 +561,11 @@ rm -rf $RPM_BUILD_ROOT %doc tmp-ruby-docs/ruby-libs/*
%changelog +* Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-3 +- Remove patch 23 altogether. Replace it with mkconfig.rb-modifying
- code in %install.
+- ruby-multilib.patch: Remove file.
- Tue Jun 22 2010 Jim Meyeringmeyering@redhat.com - 1.8.7.249-2
- Integrate addition of patch101 by Mohammed Morsi. This fixes the segv-inducing marshaling bug affecting rails-3.0.0.
The above isn't quite accurate. You need this additional change (to the %changelog text!) in order to avoid a cryptic "Package already exists: %package debuginfo" error from rpmbuild:
- code in %install.
- code in "install", above.
I guess that's rpmbuild's way of saying you must not refer to "%install" in a %changelog entry.
Please avoid to use such comprecated sed craft. While I use sed craft so many times, this type of craft makes it difficult for other persons to understand what these lines are for.
That is why I added nearly as many lines of comment as of code. Considering the size of the existing %install section and its code/comment ratio, I'm surprised that you think my addition would be difficult to understand.
Actually as I was the "Merge review" reviewer of ruby.spec I already consider that %install section is already so complecated (especially for handling documents to be installed, fixing encoding, shebang,....) and once switching from 1.8.6.x to 1.8.7.x is done, I really consider to clean up %install section (if time allows). With using ruby_1_8/ext/tk head, I had to modify %install section a bit, but I took some time to understand what part of %install I had to modify....
If understanding is the only issue, let me know if adding more comments would help.
If comprecated sed craft is needed, creating a patch is much appreciated.
I presume you would prefer a patch, so I am discarding the above, leaving the patch I used before. I cannot take David Lutterkort's suggestion to use the likes of %{_lib} without adding shell code (or fragile envvar settings) to %install.
FYI, here is my ruby-multilib.patch (patch23):
diff -ruN ruby-1.8.3.orig/mkconfig.rb ruby-1.8.3/mkconfig.rb --- ruby-1.8.7/mkconfig.rb 2008-06-06 12:39:57.000000000 +0200 +++ ruby-1.8.7/mkconfig.rb 2010-06-21 11:17:13.839498249 +0200 @@ -39,6 +39,7 @@ vars = {} has_version = false continued_name = nil continued_line = nil +lib_64 = '' File.foreach "config.status" do |line| next if /^#/ =~ line name = nil @@ -96,13 +97,21 @@ File.foreach "config.status" do |line| v_others<< v end has_version = true if name == "MAJOR"
# If the target architecture is one of the following,
# ppc64 s390x sparc64 x86_64
# then use "lib64", not "lib" in prefix.
if name == "target_cpu" and (/64"$/ =~ val or val == '"s390x"')
lib_64 = '64'end end # break if /^CEOF/ end
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = "/lib#{lib_64}/ruby/" \
print " TOPDIR = File.dirname(__FILE__).chomp!(#{prefix.dump})\n" print " DESTDIR = ", (drive ? "TOPDIR&& TOPDIR[/\A[a-z]:/i] || " : ""), "'' unless defined? DESTDIR\n" print " CONFIG = {}\n"
- RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
I think %ifarch <64 bit architecture> <apply patches specific to 64 bit> %endif is preferable because
- it clearly shows what special treatment should be done on x86_64 or so
- can avoid unneeded codes in 32 bit architecture
- and avoid to increase the size of the needed patch (or sed craft) unneededly.
If we use %ifarch..., encoding "if name == "target_cpu"...... or so handling in installed codes is unneeded.
Sorry, but I have to disagree. I find that the benefit in having identical source trees (independent of build arch) far outweighs the cost of a tiny -- and clear, imho -- patch to mkconfig.rb.
Also, my patch is slightly more maintainable. Imagine building on some new foo64 or arm64 architecture... With the /64$/ regexp in my patch, no change is required. However, with the enumerated list in %ifarch, you would have to add the new arch name to the list.
Adding 32 bit <-> 64 bit handling in the installed codes is redundant unless we support 32 bit <-> 64 bit ruby parallel install or so. Avoiding %ifarch .... %endif just because "rpmlint complaints" is questionable.
It is not merely because rpmlint complains. It is because making the canonical, patched sources differ depending on the target architecture is truly a poor practice. I think rpmlint's objection is very well justified.
With a conditionally-patched build directory, I cannot build both 32-bit and 64-bit versions of the code from the same patched source tree.
IMHO, using conditional patches is an abuse of RPM functionality and would require far more justification than is possible in this case.
Mamoru Tasaka wrote:
I think %ifarch <64 bit architecture> <apply patches specific to 64 bit> %endif is preferable because
- it clearly shows what special treatment should be done on x86_64 or so
- can avoid unneeded codes in 32 bit architecture
- and avoid to increase the size of the needed patch (or sed craft) unneededly.
If we use %ifarch..., encoding "if name == "target_cpu"...... or so handling in installed codes is unneeded.
Adding 32 bit <-> 64 bit handling in the installed codes is redundant unless
One more thing: have I misunderstood your comment?
My mkconfig.rb patch induces precisely the same change that the conditional patch does. My patch does not "[add] 32 bit <-> 64 bit handling in the installed codes". mkconfig.rb is used solely to create rbconfig.rb, at ruby-build-time. mkconfig.rb is never installed.
we support 32 bit <-> 64 bit ruby parallel install or so. Avoiding %ifarch .... %endif just because "rpmlint complaints" is questionable.
On 06/22/2010 11:08 AM, David Lutterkort wrote:
On Tue, 2010-06-22 at 12:49 +0200, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Couldn't we just get the right value from the environment ? I haven't looked if it's already in one of the standard env vars that rpmbuild sets up, but if bad comes to worst, couldn't we just do 'export LIB_PREFIX=%{_libdir}' in the spec file and then
prefix = ENV["LIB_PREFIX"].gsub(%r{^/usr}, "") + "/ruby" + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORM(There might be a macro more suitable for this than %_libdir)
David
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
The macro you were looking for was _lib, but I tried it and it looks good (no gsub /usr needed). Thanks for this.
-Mo
On 06/22/2010 06:49 AM, Jim Meyering wrote:
Mohammed Morsi wrote:
I added this patch to my specfile as well, bumped the release, and updated the changelog to include your feedback.
Hi again,
rpmlint complains about this conditionally-applied patch:
%ifarch ppc64 s390x sparc64 x86_64 %patch23 -p1 %endif
That patch (ruby-1.8.7-multilib.patch) is small enough that I'll include it here, for reference:
--- ruby-1.8.7-p249/mkconfig.rb.orig 2010-06-15 11:30:44.000000000 -0400 +++ ruby-1.8.7-p249/mkconfig.rb 2010-06-15 11:31:01.000000000 -0400 @@ -102,7 +102,7 @@
drive = File::PATH_SEPARATOR == ';'
-prefix = '/lib/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM +prefix = '/lib64/ruby/' + RUBY_VERSION.sub(/.\d+$/, '') + '/' + RUBY_PLATFORM
It is easy to perform the same task using an unconditional patch, so I wrote this replacement:
Fixed this in my patch using David's fix.
-Mo
ruby-sig@lists.fedoraproject.org
-
David Lutterkort -
Jim Meyering -
Mamoru Tasaka -
Mo Morsi