Bug 649174 - ruby-libs i686 / x86_64 conflicts
Summary: ruby-libs i686 / x86_64 conflicts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby
Version: 14
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-03 03:52 UTC by Jim Radford
Modified: 2010-11-10 01:18 UTC (History)
5 users (show)

Fixed In Version: ruby-1.8.7.302-2.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 01:18:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jim Radford 2010-11-03 03:52:08 UTC
Description of problem:

  file /usr/share/doc/ruby-libs-1.8.7.302/ext/dl/dlconfig.rb conflicts between attempted installs of ruby-libs-1.8.7.302-1.fc14.i686 and ruby-libs-1.8.7.302-1.fc14.x86_64

This is preventing me from upgrading to Fedora 14.

Comment 1 Fedora Update System 2010-11-03 19:38:38 UTC
ruby-1.8.7.302-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ruby-1.8.7.302-2.fc14

Comment 2 Fedora Update System 2010-11-04 23:41:37 UTC
ruby-1.8.7.302-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ruby'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ruby-1.8.7.302-2.fc14

Comment 3 Mo Morsi 2010-11-09 18:38:38 UTC
Hey thanks for taking care of this Mamoru, I tried this out on F14 and verified it works. Though I did have a couple questions concerning the solutions

* first of all, do we need to use miniruby? I just ask because we set normalized_cpu from the target_cpu macro at the top of this script which contains the architecture this is being built on

* as you mentioned in the patch, the file causing the conflict (and thus the wrapper you wrote) is probably unneeded as it is shipped as docs in the package. Also including dlconfig.rb in a ruby script throws an error (NameError: uninitialized constant DLTYPE), though this also occurs without your patch applied. In any case I don't have a problem with including it the way you do.

* is it standard practice to include an arch-specific subdirectory in the docs. Don't see an issue with this, but figure I'd just ask incase there was.


None of these are blockers in any case, and I voted up the fix in bodhi.

Comment 4 Mamoru TASAKA 2010-11-09 20:32:38 UTC
(In reply to comment #3)
> * first of all, do we need to use miniruby? I just ask because we set
> normalized_cpu from the target_cpu macro at the top of this script which
> contains the architecture this is being built on

- The problem here is on the line 243 of (new) ruby.spec:
---------------------------------------------------------------------
 241 cat > dlconfig.rb <<EOF
 242 require 'rbconfig'
 243 dlconfig_path=File.join(File.dirname(__FILE__), Config::CONFIG['arch'], 'dlconfig')
 244 require dlconfig_path
 245 EOF
---------------------------------------------------------------------
  Note that "Config::CONFIG['arch']" is used instead of 
  %_normalized_cpu macro (on the line 243).
  Here we cannot use %_normalized_cpu macro, because the macro
  is expanded into different value on between i686 and x86_64, and
  it again causes multilib conflict, because new wrapper dlconfig.rb
  differs between i686 and x86_64. And as "Config::CONFIG['arch']"
  is used on line 243, using this also on line 236 (i.e. 
  CONFIGARCH=$(./miniruby -rrbconfig -e "puts Config::CONFIG['arch']") )
  is more consistent.

> * as you mentioned in the patch, the file causing the conflict (and thus the
> wrapper you wrote) is probably unneeded as it is shipped as docs in the
> package. Also including dlconfig.rb in a ruby script throws an error
> (NameError: uninitialized constant DLTYPE), though this also occurs without
> your patch applied. In any case I don't have a problem with including it the
> way you do.

- "uninitialized constant DLTYPE" issue is resolved if you require
  'type.rb' in the same directory beforehand, i.e.:
-----------------------------------------------------------
[tasaka1@localhost ~]$ cd /usr/share/doc/ruby-libs-1.8.7.302/ext/dl/
[tasaka1@localhost dl]$ ruby -e 'require "type" ; require "dlconfig"'
[tasaka1@localhost dl]$
-----------------------------------------------------------
  Well, as I wrote as comments in ruby.spec, dlconfig.rb (and type.rb)
  are maybe unneeded anyway, however for now I left them as they were
  and just fixed this issue.

> * is it standard practice to include an arch-specific subdirectory in the docs.
> Don't see an issue with this, but figure I'd just ask incase there was.
  - (While new wrapper script is not "documents") IMO documents explaining
    arch-specific issue can be placed in arch-specific directory under
    /usr/share/doc. I tried quick locate and at least kernel-doc uses
    arch-specific directory for documents.

> None of these are blockers in any case, and I voted up the fix in bodhi.
- Thank you!

Comment 5 Fedora Update System 2010-11-10 01:18:06 UTC
ruby-1.8.7.302-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


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