On Wed, 2010-07-28 at 17:49 +0200, Jeroen van Meeuwen wrote:
David Lutterkort wrote:
On Thu, 2010-07-22 at 09:36 -0500, Michael Stahnke wrote:
I put together a package for rubygem-rack1 (version 1.1) for EPEL5. It is needed for things like Sinatra, Shotgun and newer versions of rails. I would love somebody could do a review so we could have it inside EPEL5.
https://bugzilla.redhat.com/show_bug.cgi?id=617228
Basically, I just made it conflict with rubygem-rack. Future packages that require rack > 1.1 could just require rubygem-rack1 instead of rubygem-rack.
Here's an evil idea: do you think it would be possible to get the yum standard config changed so that all rubygem-* packages will install instead of update (i.e. leave old versions on the machine, just as it'sdone for kernel) ?
This would make it possible to install multiple versions of gems, just as the gem system was designed. It would get rid of the biggest objection of using rpm-packaged gems, while avoiding the heinous issues with 'gem install' (like running gcc at install time)
This would have to become a YUM plugin because a new release of the package (not a new version) will replace the files on the filesystem but keep the old release entry in the rpmdb. We may want to trigger cleaning that up based on release information as opposed to version numbers in a plugin.
I don't understand - no files will be replaced by parallel installs. You'd have $GEM_HOME/gems/rails-2.3.4 and $GEM_HOME/gems/rails-2.3.8
Any files that do not go into versioned directories, like wrapper scripts for /usr/bin need to be identical between versions; the wrapper scripts already are (have a look at /usr/bin/rails as an example)
Moreover, in Fedora Updates as well as EPEL, only one version of a package can be in the repository at any given time. When updating one version of rubygem- rack, you essentially automatically kick out the other version of rubygem- rack.
That's fine - all we want is for people to not automatically clobber installed gems when they do a yum update, and allow them to update from one version to the next on their own time, and application by application.
David