On 23/07/10 06:13, 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)

I don't really use ruby in anger (apart from to support puppet, etc.) but I must admit that this thought has crossed my mind more than a few times.

R.

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.

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.

-- Jeroen

David Lutterkort wrote:

On Wed, 2010-07-28 at 17:49 +0200, Jeroen van Meeuwen wrote:

...

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)

Not if the original package is rubygem-foo-1.0-1.fc14 and the update is rubygem-foo-1.0-2.fc14.

...

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.

For example, initially, we can ship one version for rubygem-rack. If we continue down the EPEL-5 path, then an update path for rubygem- rack-0.4.0-1.el5 must be available, in order to be able to provide patches to those parties that use that version.

Suppose we then ship rubygem-rack-1.1.0-1.el5. This version will then replace the 0.4.0 version shipped until that point, and there's no problem if and when that version is installed in parallel using the installonly_pkgs feature in YUM.

However, when supplying a 0.4.0-2.el5 update to the original gem version, we push the rubygem-1.1.0-1.el5 version from the repositories. Nevermind the epoch culprit required to actually get it through the Fedora systems, we render the 1.1.0 version unavailable.

So, with saying 1.1.0 once, you also automatically choose to;

- no longer support 0.4.0 any longer, or - with every update of 0.4.0 to stable, you push out a 1.1.0 version to testing, and you cannot require rubygem(rack) >= 1.1.0 in any RPM because at this point a default system would fail a "yum install" of anything that requires rubygem(rack) >= 1.1.0 (at it's only available in testing).

A very simple solution would be;

- for the Fedora Project to keep around all packages ever released for an EPEL branch, and ship it as part of the repository, much like Red Hat itself does, and - to allow our koji mashing and updates management to include lower NEVRA package versions to be pushed out to the repository.

-- Jeroen