ruby rails, gem packages
by John Taber
most tutorials recommend installing rails and other packages using gem -
and since they change often, I'm not too sure what the value is of
trying to supply Fedora packages for the gems. In fact using the Fedora
gem packages might just mess things up especially between 1.8.6 and
1.9.1 because of the different way each handles gems.
From our standpoint, we've always just loaded ruby via the Fedora
packages and then everything via gems. This has been both easy and has
worked well. I think it is better to forget making Fedora packages of
the gems and concentrate on packages for the various Ruby language
versions - just my $.02
14 years, 1 month
new ruby 1.9.1-p243 patch for openssl error
by John Taber
thks - applied patch - compiled okay although on make install got some msgs:
no definition for ossl......
no definition for sock......
not really sure what that implies
14 years, 1 month
Re: Issues with rails right now
by Jeroen van Meeuwen
On 10/23/2009 11:34 AM, David Lutterkort wrote:
Hi David, and others,
I would like to take this discussion to the Ruby SIG list, as I think it
is of interest to more people then just the rubygem- and ruby-owners
I'm sorry for any duplicates this might cause, and I apologize in advance.
Let me try and summarize what we've been discussing previously, and
please do correct me if I'm wrong;
The release of an update for rubygem-rails and it's separate gems
(actionmailer, actionpack, activerecord, activeresource, activesupport,
hereonafter rails gems) has been quite the pain in the ass lately, as
there is a loop BuildRequirement dependency between the bunch of (now
separate) packages.
This has caused us (the rails gem maintainers) to reconsider packaging
these gems as separate sources, or from separate CVS modules if you
will. We agreed to try and determine whether using rails.tgz as one
source to rule them all. This part is on my plate, and all I'm going to
do is come up with a draft wiki page for all of us to shoot at. There's
problems here, such as "upstream does not always release a .tgz", and
I'm going to need to come up with ways to work around that, possibly
upstream which is more desirable then downstream.
Furthermore, we've discussed that updating rails gems would break
certain applications developed on another version of rails. See also
https://bugzilla.redhat.com/520843. In this particular case, it was
mentioned that setting the RAILS_GEM_VERSION on the RoR application
(environment) would indicate that a particular version of rails was to
be used, causing the application to fail if it were to be upgraded (by
using RPM packages), from 2.3.2 to 2.3.3 or 2.3.4. We decided to freeze
the Major.Minor.Teeny version of rails for every release. This means
that if by the time Fedora 12 is released the most recent version of
rails is 2.3.4, Fedora 12 would remain on rails-2.3.4 for the remainder
of its support cycle.
This however introduces a different problem; bugfixes in rails-2.3.4
(compared to rails-2.3.2) are not going to find their way to a
(supported) Fedora release. Hence, a set of patches needs to be shipped,
and that set will probably only grow over time while a Fedora release
nears the end of its life cycle. This, again, introduces yet another
problem.
The source for the RPM package is, say, rails-2.3.2.gem. We can patch
this source, even though obviously some work might be involved, but the
upstream version is and remains to be 2.3.2 (gem list will also show
2.3.2). In order for gem users to be able to upgrade to our new, patched
version of rails-2.3.2, we need to bump *its* version number (and not
just the RPM release). We also need to release the new, patched and
bumped rails gem *through upstream*.
We need to release through upstream, because Fedora is not allowed to
ship its own source files essentially creating a fork.
But, we cannot also not make the gem version 2.3.2.1 for the same
reasons we cannot release 2.3.4 (see bug #520843).
This is a problem we are going to have to overcome. This is, or at least
I think this is, the current discussion.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
Ruby 1.9.1 (or possibly 1.9.2)
by Jeroen van Meeuwen
Hi there,
Having discussed Perl packaging changes for Fedora 13 with Stepan Kasal
in Brno last September, during the Red Hat Developer Conference 2009[1],
I found his ideas (or the Perl SIGs ideas) sufficiently interesting to
experiment with myself in the case of Ruby.
I did a blog post[2] on this subject, showing off a local build of a
compat-ruby-1.9.1 package I've made. I'm still working on some of the
other troubles all of that introduces, but I wanted to let you know
where I'm thinking it could be heading towards.
Have a nice day!
-- Jeroen
[1] https://fedoraproject.org/wiki/DeveloperConference2009
[2] http://www.kanarip.com/node/872
14 years, 1 month
Introduction: Jeroen van Meeuwen
by Jeroen van Meeuwen
Hey there,
I wanted to introduce myself wrt. to what I do with Ruby, Ruby on Rails
and Ruby applications;
- I'm the owner of Ruby in current Fedora releases, after Akira Togah
orphaned it. Various people have been helping me with it as I'm both
under time constraints as well as lacking some of the more detailed
technical Ruby knowledge, and one person I wanted to name in particular
is Mamoru Tasaka.
- I'm the owner of the puppet package for scalable, consistent and
efficient configuration management, after David Lutterkort has done an
awesome job in like the 5 or 6 releases before I became his successor.
Amongst others, Todd Zullinger is a great help. Included amongst the
packages that I own is some of the dependency stack for specific
deployments (ruby-RRDtool, rubygem-mongrel, fastthread, etc, etc).
As a consultant, I -to some extent- commercially benefit from these
packages and so I think I should also step up and take some
responsibility for those packages to be available upstream, besides it
being so much more efficient and so much more fun to share and collaborate.
- I package a few Ruby Gems, which, mostly, are also dependencies of a
Ruby on Rails web application my company is developing (deadline Oct
31st). Again I can only emphasize that I find it very important I share
the work that I do as part of it's Release Engineering team with the
rest of the community. This development team uses Fedora servers (while
they are targeting EL-6 for customer deployments).
One of my responsibilities inherently, is to make sure that the platform
that is supposedly the basis of EL-6 (along with EPEL-6) is sufficiently
stable, bug-free and contains what our RoR web application requires
(hopefully also rubygem-passenger/mod_passenger, a.k.a.
mod_rails/mod_rack, for which I've submitted a review).
Furthermore, I'm involved in various other areas of the Fedora Project
such as the Ambassadors, Fedora EMEA e.V., the Spins SIG and Fedora Unity.
What I hope to get from this list is actually two-fold;
On the one end, like I said, I'm not at all experienced in programming
RoR or even just Ruby. I want to pick brains and get people that do know
how RoR and Ruby to tell me what's going on ;-) I hope to be able to ask
questions and get some answers/opinions/ideas on whether something is
going to work or destroy stuff, and whether the direction we're going in
is the right one, to ultimately improve Fedora's performance and option
value as a Ruby development platform for all of our consumers.
On the other end, I have a lot of endorsement from Operator Groep Delft
in the Netherlands (my employer) to make sure that what we do (need to
do and thus do anyway) is available to everyone, including the
not-yet-publicly-available package development on Ruby 1.9.1 -more on
that later on this list, I hope.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
