Bugzilla Bug 159922

sys-apps/coreutils-6.7-r1 moved /bin/install to /usr/bin/install. For one
thing, this change appears to break some ruby packages that use the extconf.rb
system:

# emerge ruby-libglade2
[...]
>>> Install ruby-libglade2-0.16.0-r1 into /var/tmp/portage/dev-ruby/ruby-libglade2-0.16.0-r1/image/ category dev-ruby
/bin/install -c -m 0755 libglade2.so
/var/tmp/portage/dev-ruby/ruby-libglade2-0.16.0-r1/image//usr/lib/ruby/site_ruby/1.8/i686-linux
make: /bin/install: Command not found
make: ***
[/var/tmp/portage/dev-ruby/ruby-libglade2-0.16.0-r1/image//usr/lib/ruby/site_ruby/1.8/i686-linux/libglade2.so]
Error 127

!!! ERROR: dev-ruby/ruby-libglade2-0.16.0-r1 failed.

One solution would be to symlink /bin/install to /usr/bin/install. However, the
ancient bug #39648 suggests some other reasons why install should be in /bin.

Perhaps simply installing install into /bin is the best idea.

apps shouldnt be hard coding paths

install path is unfortunately hard-coded when installing ruby. A workaround is
reemerge ruby

*** Bug 159928 has been marked as a duplicate of this bug. ***

*** Bug 160054 has been marked as a duplicate of this bug. ***

*** Bug 160269 has been marked as a duplicate of this bug. ***

*** Bug 160311 has been marked as a duplicate of this bug. ***

*** Bug 160312 has been marked as a duplicate of this bug. ***

*** Bug 160717 has been marked as a duplicate of this bug. ***

I have a similar problem with pppoe-start. It is looking for /bin/id, which
moved into /usr/bin

*** Bug 162663 has been marked as a duplicate of this bug. ***

*** Bug 162869 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> I have a similar problem with pppoe-start. It is looking for /bin/id, which
> moved into /usr/bin
> 

Moshe, pppoe-start doesn't relate to this bug really. Please open another bug
for it.

Created an attachment (id=107797) [details]
ruby eclasses patch

This patch was inspired by Eric Hodel (override mkmf.rb)

Created an attachment (id=107798) [details]
rubygems patch

The previous patch touches RUBYOPT so rubygems ebuilds need to be adjusted.

*** Bug 163510 has been marked as a duplicate of this bug. ***

A slightly different patch was committed (stricter condition, not polute stdin)

*** Bug 163939 has been marked as a duplicate of this bug. ***

*** Bug 164093 has been marked as a duplicate of this bug. ***

*** Bug 164267 has been marked as a duplicate of this bug. ***

IMHO Then this workaround should have been mentioned in ewarn. 

*** Bug 164349 has been marked as a duplicate of this bug. ***

*** Bug 164376 has been marked as a duplicate of this bug. ***

*** Bug 164378 has been marked as a duplicate of this bug. ***

gems packages were _not_ fixed (I thought it would use ruby_src_unpack but it
in fact did not). gems.eclass is fixed now (revision 1.15). Everybody whose
bugs are marked duplicated please test and feedback.
Thank you.

*** Bug 164392 has been marked as a duplicate of this bug. ***

Sorry, have I missed something here? Given the flood of dupes, this doesn't
appear to be fixed at all...

Will we call this an "amarok effect"? ;) (which now pulls in mongrel ruby
server)

Oh I forgot another thing :( I focused on ebuild installation only. This bug
still remains if you install things by hand (even via rubygems)
Maybe it's time to make a version bump for dev-lang/ruby

Bumping dev-lang/ruby may cause people to run into bug 161566 now that autoconf
2.61 is stable. If possible I think it would be good to have a resolution on
this first, although I don't know how many people still use glibc 2.3.x

Every normal sparc user still uses glibc-2.3.x (only place it is unmasked is in
an experimental gcc-4.1.x profile at the moment)

*** Bug 164637 has been marked as a duplicate of this bug. ***

*** Bug 164658 has been marked as a duplicate of this bug. ***

Attempt to fix this bug is the reason of bug 164525 :( I reverted changes I
made for this bug.

Created an attachment (id=108755) [details]
eclass patch

A less intrusive approach (overload rbconfig.rb)

*** Bug 164725 has been marked as a duplicate of this bug. ***

The "Amarok Effect" ...

Can confirm that remerging Ruby fixed the problem with installing Fastthread
(Bug 164725).

*** Bug 164900 has been marked as a duplicate of this bug. ***

*** Bug 164931 has been marked as a duplicate of this bug. ***

*** Bug 164964 has been marked as a duplicate of this bug. ***

Can confirm too that remerging ruby-1.8.5-p12 allows fastthread-0.6.3 to merge
and install.
Using glibc-2.5 on ~x86

*** Bug 165112 has been marked as a duplicate of this bug. ***

*** Bug 165162 has been marked as a duplicate of this bug. ***

*** Bug 165171 has been marked as a duplicate of this bug. ***

also can confirm re-emerging ruby fixes this.

confirming, that re-emerging ruby fixes this
Maybe those who upgrade amaroK should be notified that this might be necessary.

People stop confirming the issue, this bug is already noisy enough as it is due
to users that don't bother themselves with searching for duplicates. :(

*** Bug 165295 has been marked as a duplicate of this bug. ***

*** Bug 165653 has been marked as a duplicate of this bug. ***

(In reply to comment #34)
> Created an attachment (id=108755) [edit] [details]
> eclass patch
> 
> A less intrusive approach (overload rbconfig.rb)
> 

I can confirm that this patch allows fastthread to install.

Thanks.

*** Bug 165988 has been marked as a duplicate of this bug. ***

*** Bug 166012 has been marked as a duplicate of this bug. ***

*** Bug 166714 has been marked as a duplicate of this bug. ***

*** Bug 166716 has been marked as a duplicate of this bug. ***

*** Bug 167161 has been marked as a duplicate of this bug. ***

*** Bug 167966 has been marked as a duplicate of this bug. ***

I'm tempted to close this bug as CANTFIX. This bug is unlikely to happen again
in the near future. And no report for two months. Any other ideas?

Perhaps it is a good idea to leave the bug open for some time, because
coreutils-6.7 is now being marked stable on several arches (I noticed it on
amd64 this morning). So many people will only run into this now, and if we
close the bug less people will find it leading to many duplicates.

Or give warning in preinst/postinst

(In reply to comment #58)
> Or give warning in preinst/postinst
> 
Although I doubt this, I have modified all dev-lang/ruby ebuilds and hoped
somebody would notice the message.

(In reply to comment #9)
> I have a similar problem with pppoe-start. It is looking for /bin/id, which
> moved into /usr/bin
> 

Did you open a bug for this?

*** Bug 173956 has been marked as a duplicate of this bug. ***

(In reply to comment #60)
> (In reply to comment #9)
> > I have a similar problem with pppoe-start. It is looking for /bin/id, which
> > moved into /usr/bin
> Did you open a bug for this?

Please don't; there's already one with zillion of duplicates; plus you
shouldn't be using this stuff at all.

(In reply to comment #62)
> (In reply to comment #60)
> > (In reply to comment #9)
> > > I have a similar problem with pppoe-start. It is looking for /bin/id, which
> > > moved into /usr/bin
> > Did you open a bug for this?
> 
> Please don't; there's already one with zillion of duplicates; plus you
> shouldn't be using this stuff at all.
> 

Jakub:

Could you give me a reference to this bug?  Also, I don't understand your last
comment.  Who shouldn't be using what?

(In reply to comment #63)
> Could you give me a reference to this bug?  

Maybe you could just use search and find Bug 159747 and loads of duplicates? 

> Also, I don't understand your last comment.  Who shouldn't be using what?

You shouldn't use pppoe-start at all.
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4&chap=3#doc_chap4

</end of completely OT debate>

*** Bug 174797 has been marked as a duplicate of this bug. ***

I just tried to emerge ruby-mysql and got the /bin/install error.

I then tried to "emerge -av dev-lang/ruby dev-ruby/mysql-ruby" and got the same
error...

Then I realized that you all are talking about 1.8.5_p12, which is masked and
_p2 is the one that I remerged. Ironic that mysql-ruby is marked stable though?

Can you please mark 1.8.5_p35 (or _p12) as stable then?

locutus ~ # eix dev-lang/ruby
[I] dev-lang/ruby
     Available versions:  (1.8)  1.8.4-r3 1.8.5_p2 ~1.8.5_p12 ~1.8.5_p35
~1.8.6_pre1 ~1.8.6_pre3 ~1.8.6
     Installed versions:  1.8.5_p2(1.8)(15:52:03 04/20/07)(-cjk -debug doc
examples ipv6 -socks5 threads -tk)
     Homepage:            http://www.ruby-lang.org/
     Description:         An object-oriented scripting language

*** Bug 175507 has been marked as a duplicate of this bug. ***

*** Bug 175991 has been marked as a duplicate of this bug. ***

*** Bug 176696 has been marked as a duplicate of this bug. ***

*** Bug 177358 has been marked as a duplicate of this bug. ***

Closing this bug; re-emerge ruby if you hit this issue.

*** Bug 178228 has been marked as a duplicate of this bug. ***

I've bumped the currently stable ruby-1.8.5_p2 to ruby-1.8.5_p2-r1 and filed
bug 178346 to stabilize this as soon as possible. This will cause ruby users to
recompile their ruby and thus solve the issue.

I have not added a dependency on coreutils-6.7-r1 because this would cause
problems stabling this ebuild for some profiles (mostly the selinux versions).
These profiles will have to deal with the issue at a later date.

*** Bug 178440 has been marked as a duplicate of this bug. ***

How about a warning when coreutils is upgraded?

Fixed on sparc by ruby-1.8.5_p2-r1 (Bug 178346).

*** Bug 178462 has been marked as a duplicate of this bug. ***

*** Bug 178486 has been marked as a duplicate of this bug. ***

*** Bug 199189 has been marked as a duplicate of this bug. ***

*** Bug 209016 has been marked as a duplicate of this bug. ***