Bug 789532 - ruby-1.9.pc is insufficient and suboptimal
Summary: ruby-1.9.pc is insufficient and suboptimal
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-11 02:20 UTC by John Ellson
Modified: 2013-03-28 10:46 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-28 10:46:20 UTC


Attachments (Terms of Use)

Description John Ellson 2012-02-11 02:20:52 UTC
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 12:35:24 UTC
Thank you for the report. I'll take a look into. It sounds reasonable.

Comment 2 Bohuslav "Slavek" Kabrda 2012-02-20 09:03:56 UTC
(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 15:33:20 UTC
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 16:08:19 UTC
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 16:28:56 UTC
https://bugs.ruby-lang.org/issues/6052   created for the vendorarchdir in ruby.pc issue.

Comment 6 Vít Ondruch 2012-04-13 08:06:44 UTC
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 14:19:28 UTC
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 10:45:11 UTC
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 11:13:57 UTC
(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 12:12:34 UTC
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 15:34:18 UTC
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 16:07:17 UTC
Thank you. I will check this later on F-18 and below.

Comment 13 Fedora Update System 2013-01-19 18:18:38 UTC
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 18:19:32 UTC
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 18:24:31 UTC
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 19:45:23 UTC
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 22:18:16 UTC
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 16:59:56 UTC
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 17:18:02 UTC
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 11:29:31 UTC
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 10:46:20 UTC
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.