Ruby 2.0.0_p594 fails to install due to file collisions with dev-ruby/json-1.8.0 (see attached build.log). Ruby requires the json package, even though ruby ships with only slightly older (1.7.7) version. With exactly the same parser.c file # find json-1.8.0/ ruby-2.0.0-p594/ext/json/ -name parser.c | xargs sha1sum e3e3ab4c86ee5f7f1a63fc057285959729186a53 json-1.8.0/ext/json/ext/parser/parser.c e3e3ab4c86ee5f7f1a63fc057285959729186a53 ruby-2.0.0-p594/ext/json/parser/parser.c which is why the two packages provide the same debug file. # ls -l /usr/lib/debug/.build-id/68/616d7d9c982e6fd3cb7722aa51fbd85d2423a2* lrwxrwxrwx 1 root root 65 11-08 16:02 /usr/lib/debug/.build-id/68/616d7d9c982e6fd3cb7722aa51fbd85d2423a2 -> /usr/lib64/ruby/gems/2.0.0/gems/json-1.8.0/lib/json/ext/parser.so lrwxrwxrwx 1 root root 76 11-08 16:02 /usr/lib/debug/.build-id/68/616d7d9c982e6fd3cb7722aa51fbd85d2423a2.debug -> ../../usr/lib64/ruby/gems/2.0.0/gems/json-1.8.0/lib/json/ext/parser.so.debug Reproducible: Always
Created attachment 388876 [details] build.log
*** This bug has been marked as a duplicate of bug 491452 ***
I am glad that the collision problem has been managed more or less (the search engine is really poor because it didn't find bug 491452 when I asked for "dev-lang/ruby json"). However, I am still not sure why dev-lang/ruby-2.0.0_p594 requires separate >=dev-ruby/json-1.7.7 package.
Besides, applying the fix from https://bugs.gentoo.org/show_bug.cgi?id=526144#c5 makes dev-lang/ruby not provide the build-id files which IMHO can be deemed merely as a workaround for both this and bug 491452.
(In reply to Łukasz Stelmach from comment #3) > I am glad that the collision problem has been managed more or less (the > search engine is really poor because it didn't find bug 491452 when I asked > for "dev-lang/ruby json"). However, I am still not sure why > dev-lang/ruby-2.0.0_p594 requires separate >=dev-ruby/json-1.7.7 package. Because we prefer to unbundle code in Gentoo and many packages will request the gem version of the json code so that is what we need to provide in any case. Even if we would not unbundle the json code from dev-lang/ruby you would get the same build-id issues since in its current state is not compatible with how Gentoo manages things in terms of file collisions.
If I understand the term "unbundle" correctly, json isn't actually unbundled. Both packages have some common files (see attachments). Including parser.so ruby: ./usr/lib64/ruby/2.0.0/x86_64-linux/json/ext/parser.so json: ./usr/lib64/ruby/gems/2.0.0/gems/json-1.8.0/lib/json/ext/parser.so If they were removed from ruby before installing/merging/packaging there would be no collision.
Created attachment 389016 [details] List of files in dev-ruby/json-1.8.0
Created attachment 389022 [details] List of files in dev-lang/ruby-2.0.0_p594
(In reply to Łukasz Stelmach from comment #6) > If I understand the term "unbundle" correctly, json isn't actually > unbundled. Both packages have some common files (see attachments). Including > parser.so > > ruby: > ./usr/lib64/ruby/2.0.0/x86_64-linux/json/ext/parser.so > > json: > ./usr/lib64/ruby/gems/2.0.0/gems/json-1.8.0/lib/json/ext/parser.so > > > If they were removed from ruby before installing/merging/packaging there > would be no collision. You are correct in that we don't properly unbundle anymore. Unfortunately proper unbundling would not make a difference since we still need to compile parser.so to account for the bootstrap scenario, and at that point the build-id file would already be generated.
