I just tried to upgrade to jruby 1.4.0-r4 and got the following message: * /usr/share/jruby/lib/ruby/gems is a symlink. Please remove this symlink. * Unmerging the old jruby version should also fix the problem(s). Fine, I thought, unmerged the package, and tried again. Same problem. So I did this: # qfile -v /usr/share/jruby/lib/ruby/gems dev-ruby/rspec-1.3.0 (/usr/share/jruby/lib/ruby/gems) dev-ruby/jruby-openssl-0.6-r1 (/usr/share/jruby/lib/ruby/gems) dev-ruby/rake-0.8.7-r3 (/usr/share/jruby/lib/ruby/gems) # cd /var/db/pkg; grep '/usr/share/jruby/lib/ruby/gems$' dev-ruby/*/CONTENTS dev-ruby/jruby-openssl-0.6-r1/CONTENTS:dir /usr/share/jruby/lib/ruby/gems dev-ruby/rake-0.8.7-r3/CONTENTS:dir /usr/share/jruby/lib/ruby/gems dev-ruby/rspec-1.3.0/CONTENTS:dir /usr/share/jruby/lib/ruby/gems So (probably due to me having jruby among my RUBY_TARGETS) some packages considered that symlink to be a directory and installed files inside it. I guess that might be the reason portage (2.2_rc61) didn't remove the symlink when I unmerged jruby-1.4.0-r3, although unmerging the other packages didn't remove it either. That in turn might be because it was a symlink but the removed packages expected it to be a dir. I could remove the symlink manually, but doing so would probably orphan all jruby files from these other packages. So the proper approach would be unmerging those first as well, probably before jruby itself. Or finding a way to keep the symlink until portage feels it's safe to remove it during normal package cleaning.
You probably did something wrong because the 1.3.1-r1+ versions are a dependency of jruby targets *and* they already required the symlink to be deleted.
(In reply to comment #1) > You probably did something wrong because the 1.3.1-r1+ versions are a > dependency of jruby targets *and* they already required the symlink to be > deleted. Nope, they didn't. They only complained about symlinks not pointing to dirs: jruby-1.4.0-r3.ebuild: if [[ ! -d "${GEMS}" && -L "${GEMS}" ]]; then jruby-1.4.0-r4.ebuild: if [[ -L ${directory} ]]; then As the symlink used to point to /usr/$(get_libdir)/ruby/gems as heritage from jruby-1.3.1 and as that directory exists on my system because packages like dev-ruby/rubygems-1.3.5 own files in it, the old ebuilds didn't complain. The new ebuild is stricter, which makes a lot of sense, but the migration instructions are still likely to cause orphaned files, e.g. if a package like jruby-openssl was installed only for jruby but not for ruby18.
Uhm ouch, Martin you got me there, the older code was broken and now we're in a bit of trouble indeed. But unfortunately I wouldn't know what to actually suggest to fix this :(
(In reply to comment #3) > But unfortunately I wouldn't know what to actually suggest to fix this :( I'd say the proper solution would be unmerge, remove symlink, remerge: emerge -an app-portage/gentoolkit equery -qC b /usr/share/jruby/lib/ruby/gems | sed s/^/=/ > ~/jruby.fix emerge -1C $(< ~/jruby.fix) rm /usr/share/jruby/lib/ruby/gems emerge -1 $(< ~/jruby.fix) rm ~/jruby.fix Haven't tested this, but it should work. You might either suggest the sequence, or wrap it into a script file and suggest running that. Up to you. If you do use a script, you might do some case distinction and use "qfile -qvC" instead of "equery -qC b" if gentoolkit isn't installed but portage-utils is. If you print the commands for users to execute, that's probably too much trouble.
(In reply to comment #4) That seemed to do the trick for me.
Thanks, added the sequence to the ebuild (it worked for myself).
(In reply to comment #6) > Thanks, added the sequence to the ebuild (it worked for myself). I'd say the whole message should be eerror, not echo. Otherwise users might receive an email or similar elog-configured error message, and miss the echo part.
(In reply to comment #7) > (In reply to comment #6) > > Thanks, added the sequence to the ebuild (it worked for myself). > > I'd say the whole message should be eerror, not echo. Otherwise users might > receive an email or similar elog-configured error message, and miss the echo > part. If it fails, they should read the whole output on console and not just some incomplete logs, imho. Should be also easier to copy/paste this way.
