Red Hat Bugzilla – Bug 789532
ruby-1.9.pc is insufficient and suboptimal
Last modified: 2013-03-28 06:46:20 EDT
Description of problem: PKG_CHECK_MODULES provides mechanisms for selecting or constraining versions of the modules, but this mechanism is defeated when the module name includes its version number. "ruby-1.9.pc" should be renamed "ruby.pc" so that, IFF the user needs it, statements like: PKG_CHECK_MODULES(RUBY, [ruby >= 1.9],[...] can be used. Also, the current ruby-1.9.pc doesn't provide a value for "vendorarchdir" and so is insufficient for packages like graphviz to build ruby extensions without still resorting to ruby's (ever changing) RbConfig (nee: Config) mechanism. Version-Release number of selected component (if applicable): ruby-devel-1.9.3.0-7.fc17 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: See configure.ac in latest upstream graphviz from www.graphviz.org.
Thank you for the report. I'll take a look into. It sounds reasonable.
(In reply to comment #0) > Description of problem: > > PKG_CHECK_MODULES provides mechanisms for selecting or constraining versions of > the modules, but this mechanism is defeated when the module name includes its > version number. > "ruby-1.9.pc" should be renamed "ruby.pc" so that, IFF the user needs it, > statements like: > PKG_CHECK_MODULES(RUBY, [ruby >= 1.9],[...] > can be used. > > Also, the current ruby-1.9.pc doesn't provide a value for "vendorarchdir" > and so is insufficient for packages like graphviz to build ruby extensions > without still resorting to ruby's (ever changing) RbConfig (nee: Config) > mechanism. > > Additional info: > See configure.ac in latest upstream graphviz from www.graphviz.org. Hi John, I'm no expert on .pc files, but here is what I get from this: - Renaming ruby-1.9.pc to ruby.pc would solve the cases when you need to pass parameter for the /usr/include/x86_64-linux/ruby/config.h to configure, that seems to be clear. - Defining vendorarchdir and vendorlibdir is not a problem but how would it solve the problem with graphviz? And how would you propose to use these - passing them as additional Cflags? Thanks.
No, not Cflags. The value is need for installation, not compilation. Assuming ruby.pc contains a line like: vendorarchdir=${libdir}/ruby/vendor_ruby configure.ac would extract it by using something like: PKG_CHECK_MODULES(RUBY, [ruby >= 1.9],[ RUBY_INSTALL_DIR=`pkg-config --variable vendorarchdir ruby` AC_SUBST([RUBY_INSTALL_DIR]) ],[ #deal with pre 1.9 ruby's ])
John, I think that we should split this issue in two. One is the ruby.pc filename and I have asked upstream about renaming the ruby-1.9.pc: https://bugs.ruby-lang.org/issues/6051 The other, trickier, is the addition of options for installation configuration, as you mention in comment #3. Would you mind to open new, separate issue for this topic?
https://bugs.ruby-lang.org/issues/6052 created for the vendorarchdir in ruby.pc issue.
The #6051 was solved by https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/34880 so we can backport if for Ruby 1.9.3 Not sure about the #6052 though.
Hi John, In F19+, there will be provided nonversioned ruby.pc. I pushed the change into git [1]. Do you think it is worth of backporting this change into older Fedoras? It should be possible, since the changes were backported into 1.9.3 by upstream. I am just unsure if we will not break other things. Mamoru? Any comments? Also, the .pc should already provide values such as "vendorarchdir" even in F17, if I am not mistaken, is it right? [1] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=ruby-2.0&id=3e8ccc1ce677ef739347417c3cfdb312b1b335b1
The safest solution is to provide both ruby.pc and ruby-1.9.pc on F-18 and below (on F-19, just provide ruby.pc). I can commit this change. For vendorarchdir, currently [mtasaka@localhost ~]$ rpm -q ruby-devel ruby-devel-1.9.3.362-24.fc18.i686 [mtasaka@localhost ~]$ pkg-config --variable=vendorarchdir ruby-1.9 /usr/share/ruby/vendor_ruby/i386-linux This is not correct and needs fixing (/usr/share must not arch-dependent, so containing "i386-linux" is wrong). Usually ruby related headers and arch-dependent C modules are installed under %ruby_sitearchdir, so perhaps pkg-config --variable=vendorarchdir ruby-1.9 should return this value.
(In reply to comment #8) > The safest solution is to provide both ruby.pc and ruby-1.9.pc on F-18 and > below (on F-19, just provide ruby.pc). I can commit this change. Agree with that. > For vendorarchdir, currently > [mtasaka@localhost ~]$ rpm -q ruby-devel > ruby-devel-1.9.3.362-24.fc18.i686 > [mtasaka@localhost ~]$ pkg-config --variable=vendorarchdir ruby-1.9 > /usr/share/ruby/vendor_ruby/i386-linux > This is not correct and needs fixing (/usr/share must not arch-dependent, so > containing "i386-linux" is wrong). Good catch. > Usually ruby related headers and arch-dependent C modules are installed > under %ruby_sitearchdir, so perhaps pkg-config --variable=vendorarchdir > ruby-1.9 should return this value. This should return the same value as following command: $ ruby -rrbconfig -e "puts RbConfig::CONFIG['vendorarchdir']" /usr/lib64/ruby/vendor_ruby Seems that ruby-1.9.3-added-site-and-vendor-arch-flags.patch should be extended to cover this, but I need to get closer look though.
Small modification: (In reply to comment #8) > For vendorarchdir, currently > Usually ruby related headers and arch-dependent C modules are installed > under %ruby_sitearchdir, this is %ruby_vendorarchdir (also ruby -rrbconfig -e "puts RbConfig::CONFIG['vendorarchdir']" as you said)
I fixed (hopefully) it in ruby-2.0 branch [1]. The configuration process can expand these variables, which is more error prone IMO. Unfortunately I am afraid I cannot submit this patch upstream, until ruby-core accepts [2] and ruby-1.9.3-arch-specific-dir.patch probably as well :/ [1] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=ruby-2.0&id=fd812ccb12aff4611ee6b0617686802e1ee58661 [2] http://redmine.ruby-lang.org/issues/5281
Thank you. I will check this later on F-18 and below.
ruby-1.9.3.374-27.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ruby-1.9.3.374-27.fc18
ruby-1.9.3.374-27.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ruby-1.9.3.374-27.fc17
I backported ruby-2.0.0-Expand-ruby.pc-variable-by-configuration-process.patch to 1.9.3.x. vendorarchdir now seems correct, thank you.
Re Comment #9 & #8 > Vít Ondruch 2013-01-18 06:13:57 EST > > (In reply to comment #8) > > The safest solution is to provide both ruby.pc and ruby-1.9.pc on F-18 and > > below (on F-19, just provide ruby.pc). I can commit this change. > > Agree with that. What happened to this idea? There is no softlink in the latest rpm. [ellson@rawhide-64 ~]$ ls /usr/lib64/pkgconfig/ruby* /usr/lib64/pkgconfig/ruby.pc [ellson@rawhide-64 ~]$ rpm -q ruby ruby-1.9.3.374-27.fc19.x86_64
Never mind .. ignore that .. you did say only FC18 and earlier ... Today's graphviz development snapshot now fixed to find ruby.pc in rawhide.
ruby-1.9.3.374-27.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
ruby-1.9.3.374-27.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
This was fixed upstream [1]. Going to drop the patch from ruby-2.0 branch. I am not sure if it is worth of asking for backport to Ruby 1.9.3. https://github.com/ruby/ruby/commit/29c214e4a058fc4017ab0c0bf5c36b5bad203b5b#diff-2
This should be fixed in all Fedoras now.