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
> (not a new version) will replace the files on the filesystem but
> release entry in the rpmdb. We may want to trigger cleaning that
> 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
> Moreover, in Fedora Updates as well as EPEL, only one version of
> be in the repository at any given time. When updating one
> rack, you essentially automatically kick out the other version
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
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
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,
- to allow our koji mashing and updates management to include lower NEVRA
package versions to be pushed out to the repository.