After reviewing this bug
https://bugzilla.redhat.com/show_bug.cgi?id=522162 and the links
contained therein, it appears that we should move the rails stack on
EPEL 5 to at least 2.2.3, and possibly later. Since this is rails, it
will likely cause breakage for existing applications.
Thoughts and/or ideas?
I am running Fedora 12 with Rails 2.3.4 installed. Everything was working
fine, then last night I got an update from yum for Rack 1.1. After
installing that, my working rails apps failed to load. Creating a new test
RubyGem version error: rack(1.1.0 not ~> 1.0.0) (Gem::LoadError)
Has anyone else hit this issue? If more detail is needed, let me know.
Hey just a quick update w/ some work I've been doing towards getting a
platform which to test Ruby on Fedora. I've pushed many updates to
Polisher (http://github.com/movitto/polisher), the focus of which has
been expanded to manage any generic upstream project release process.
Special cases have also been added to make use of the gemcutter API and
gem2rpm for gem based projects. I've also added a Ruby DSL which can be
used to descibe any number of projects w/ sources, and setup
post-processing workflows to be executed on releases.
I've grabbed several popular Ruby related packages in Fedora, made some
small modifications to the specs, and setup Polisher scripts
(http://github.com/movitto/polisher-scripts) to run through simulated
releases of various versions, setting up the following yum repos
(http://projects.morsi.org/polisher/repos) in the process:
* stable - same packages that are currently in Fedora updates
* maintenance - later releases in the same major version branch of
the packages currently in stable
* devel - packages that work w/ Ruby 1.9 (great <a
* rawhide - all latest ruby project versions
By tweaking the Polisher scripts and rpm spec file templates, the
contents of these repos can be changed and new ones can be setup for any
target software stack.
You can simply point a yum repo entry towards any of those repos
beforing running a yum update to get all the latest Ruby packages
provided by that repo, through there most likely will be breakage as
Polisher and the scripts themselves are a work in progress.
I'm also setting up various virt appliances, each pointing at a
different Polisher generated repo by default, so that anyone can just
download a VM image containing Fedora and a complete Ruby stack for
whichever version of Ruby they want to use. It's a work in progress, I
will put links up on my blog (http://mo.morsi.org/blog) as I upload the
Obviously this is all a work in progress and it is quite a bit of effort
to get Polisher scripts written for every Ruby related package, but if
this thing starts rolling, I can see this as being a useful tool in the
"upstream project to Fedora repo" process as mass parallel source
releases can be triggered and handled easily in a committable /
reproducible / reliable fashion. If anyone has any cycles I'd appreciate
any help (patches, testing, etc).
Stay tuned for more updates.
I'm currently working on packaging Chef
(http://wiki.opscode.com/display/chef/Home) which has presented some
some interesting challenges and I need some advice.
Currently their primary distribution method and focus is rubygems,
though they have produced Debian packages. When using Chef via rubygems
the actual setup is done by downloading and running a 'bootstrap' tar.gz
which does a number of things all over the system (putting configs in
place, installing more gems etc). The goal of packaging Chef is to avoid
this arbitrary 'bootstrap' step and contain everything required to run
Chef within packages.
Packaging the gems is easy enough, but the daemons, configs and
directories it requires seem to fall outside of the scope of what the
current rubygems packages do (as far as I can tell).
For my first target, the Chef client, my thinking is to produce 2
packages - the main rubygem then a 'chef' subpackage that ships the
binaries, man pages, init scripts etc. Check it out here:
I couldn't find anything in the wiki about *not* doing this with
subpackages but I'm unsure if it would be frowned upon.
Matthew Kent | http://magoazul.com