Bug 649174

Summary: ruby-libs i686 / x86_64 conflicts
Product: [Fedora] Fedora Reporter: Jim Radford <radford>
Component: rubyAssignee: Mamoru TASAKA <mtasaka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: jeremy, mmorsi, mtasaka, tagoh, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ruby-1.8.7.302-2.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 01:18:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.