Summary: | dev-java/jruby-1.4.0-r4: gems symlink removal breaks packages | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Development | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ruby |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin von Gagern
2010-01-25 15:39:01 UTC
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. |