Review for rubygem-rack1

[Jeroen van Meeuwen]

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