| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(Portage version: 2.2.0_alpha55/cvs/Linux x86_64)
|
|
|
|
| |
(Portage version: 2.1.9.41/cvs/Linux ia64)
|
|
|
|
| |
(Portage version: 2.2.0_alpha1/cvs/Linux x86_64)
|
|
|
|
| |
(Portage version: 2.1.8.3/cvs/Linux i686)
|
|
|
|
|
|
| |
is still compatible with the gems eclass.
(Portage version: 2.1.8.3/cvs/Linux x86_64)
|
|
|
|
|
|
|
|
|
| |
customisation, all clear for upstream, while we install our own defaults in a separate file exactly as upstream intended.
This new version installs in /usr/local rather than /usr, so that whatever the user installs, it's not going to collide or mess with Portage-installed gems. Also, we no longer do any per-implementation patching, and we only special-case Ruby 1.9 for what concern the auto_gem file (instead of keeping four copies of the same identical file in files/).
Documentation is not currently building right, but tests are executed (they fail for JRuby, that is known.
Note that the -r1 version has been dropped, so for ~alpha and ~arm (which will have to re-keyword -r2) this causes a faux-downgrade to 1.3.7, but the changes in -r1 only related to Ruby 1.9 anyway.
(Portage version: 2.2_rc67/cvs/Linux x86_64)
|
|
~/.gem/ruby/1.9.1 instead of ~/.gem/ruby19/1.9.1. The systemwide installation directory will follow that change eventually. Closes bug 319977.
(Portage version: 2.2_rc67/cvs/Linux x86_64)
|