Bug 789532 - ruby-1.9.pc is insufficient and suboptimal
ruby-1.9.pc is insufficient and suboptimal
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ruby (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vít Ondruch
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-10 21:20 EST by John Ellson
Modified: 2013-03-28 06:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-28 06:46:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Ellson 2012-02-10 21:20:52 EST
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.
Comment 1 Vít Ondruch 2012-02-13 07:35:24 EST
Thank you for the report. I'll take a look into. It sounds reasonable.
Comment 2 Bohuslav "Slavek" Kabrda 2012-02-20 04:03:56 EST
(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.
Comment 3 John Ellson 2012-02-20 10:33:20 EST
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
           ])
Comment 4 Vít Ondruch 2012-02-20 11:08:19 EST
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?
Comment 5 John Ellson 2012-02-20 11:28:56 EST
https://bugs.ruby-lang.org/issues/6052   created for the vendorarchdir in ruby.pc issue.
Comment 6 Vít Ondruch 2012-04-13 04:06:44 EDT
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.
Comment 7 Vít Ondruch 2013-01-17 09:19:28 EST
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
Comment 8 Mamoru TASAKA 2013-01-18 05:45:11 EST
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.
Comment 9 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.

> 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.
Comment 10 Mamoru TASAKA 2013-01-18 07:12:34 EST
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)
Comment 11 Vít Ondruch 2013-01-18 10:34:18 EST
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
Comment 12 Mamoru TASAKA 2013-01-18 11:07:17 EST
Thank you. I will check this later on F-18 and below.
Comment 13 Fedora Update System 2013-01-19 13:18:38 EST
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
Comment 14 Fedora Update System 2013-01-19 13:19:32 EST
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
Comment 15 Mamoru TASAKA 2013-01-19 13:24:31 EST
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.
Comment 16 John Ellson 2013-01-23 14:45:23 EST
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
Comment 17 John Ellson 2013-01-23 17:18:16 EST
Never mind .. ignore that .. you did say only FC18 and earlier ...

Today's graphviz development snapshot now fixed to find ruby.pc in rawhide.
Comment 18 Fedora Update System 2013-02-01 11:59:56 EST
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.
Comment 19 Fedora Update System 2013-02-01 12:18:02 EST
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.
Comment 20 Vít Ondruch 2013-02-11 06:29:31 EST
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
Comment 21 Vít Ondruch 2013-03-28 06:46:20 EDT
This should be fixed in all Fedoras now.

Note You need to log in before you can comment on or make changes to this bug.