I have a Debian 4 machine with Ruby 1.8.6 (installed from source) and
some gems including Rails 2.1 and Phusion Passenger 2.0.3 (mod_rails,
which needs fastthread and rack gems). I want to update to the latest
patch of that version (1.8.6-p287), but I have my concerns. Can I do
it safely? Is there any warning, any catch? Will I have to reinstall
RubyGems and every single gem? What’s your advice before patching?
Will all the dependent apps be screwed up? I’m asking this because,
unfortunately, there’s no “make uninstall” command after installing
Ruby from source… Really! I tried, but failed miserably. The only
choice I see is to erase the folder where it’s located, I doubt
installing the patch overwrites all the files.
I have a Debian 4 machine with Ruby 1.8.6 (installed from source) and
some gems including Rails 2.1 and Phusion Passenger 2.0.3 (mod_rails,
which needs fastthread and rack gems). I want to update to the latest
patch of that version (1.8.6-p287)
Do you have a particular reason to do this?
I only ask because there have been bad problems with Rails running under
Ruby released versions later than p114. I’m not sure if p287 has fixed
them all (perhaps others can comment on this). If you want stability in
production, and your distribution has a p111 or p114 plus just the
security patches, then personally I’d stick with that.
Unfortunately there is no official “stable” branch of Ruby at present -
that is, one which receives security fixes only. The 1.8.6 branch has
received a number of “enhancements” which have turned out to break
things. It’s therefore up to the distro maintainers to provide their own
“stable” version of Ruby.
I only ask because there have been bad problems with Rails running under
Ruby released versions later than p114. I’m not sure if p287 has fixed
them all (perhaps others can comment on this). If you want stability in
production, and your distribution has a p111 or p114 plus just the
security patches, then personally I’d stick with that.
I understand your point of view, but as you can see, I have the first
release (patch level 0), so I’m very concerned. Debian only has v.
1.8.5, and I’m also working with Rails 2.1. I always pass through the
Ruby website and didn’t know the importance of the patch but now.
I don’t know if Rails will break, but it didn’t die on me. I’m going
to install the recent version tomorrow. Wish me luck because I’m going
armed to the teeth.
from source… Really! I tried, but failed miserably. The only choice I
see is to erase the folder where it’s located, I doubt installing the
patch overwrites all the files.
Any suggestion is welcomed. Later…
Juan “The N.” Escajadillo
Upgrade to 1.8.7 from backports.org
There will be no need to reinstall rubygems or your gems, though some C
extensions that work with internal structures in the ruby interpreter
may
require reinstallation. (I don’t have a list of what would, but let’s
just say those are few and far between.)
I only ask because there have been bad problems with Rails running under
Ruby released versions later than p114. I’m not sure if p287 has fixed
them all (perhaps others can comment on this). If you want stability in
production, and your distribution has a p111 or p114 plus just the
security patches, then personally I’d stick with that.
I understand your point of view, but as you can see, I have the first
release (patch level 0), so I’m very concerned. Debian only has v.
1.8.5, and I’m also working with Rails 2.1. I always pass through the
Ruby website and didn’t know the importance of the patch but now.
apt-get install checkinstall
then:
./configure <options, make sure to set the "postfix the binary with
the version" option>
make
checkinstall
checkinstall will ask you several questions about your package, and then
run ‘make install’ but instead of putting it into your normal filesystem
it will install it into a faked fs. then, it will build a .deb out of
the contents.
On Sun, 12 Oct 2008 11:41:58 -0500, Erik H. wrote:
release (patch level 0), so I’m very concerned. Debian only has v.
checkinstall
checkinstall will ask you several questions about your package, and then
run ‘make install’ but instead of putting it into your normal filesystem
it will install it into a faked fs. then, it will build a .deb out of
the contents.
HTH.
-Erik
You don’t want to do that in this case because there are a whole bunch
of
Ruby packages in Debian that will be replaced by one if you do this, and
wierd unexplained packaging conflicts will abound if you try to install
one of those parts of ruby in conjunction with your own package.
Since you’re running Debian Stable, why don’t you just upgrade to 1.8.7
from backports.org.
On Sun, 12 Oct 2008 17:03:23 -0500, Ryan D. wrote:
On Oct 12, 2008, at 12:23 , Brian C. wrote:
Is there general consensus on the stability of 1.8.7pXXX with Rails?
Anyone running it in large-scale production?
I wouldn’t touch it with a 10 foot pole for production. Esp not for
rails. I think that was terrible advice.
I don’t know Rails, but I do know Debian (and ruby). Using checkinstall
for something that’s in Debian’s archives is as bad (if not worse)
advice
than using 1.8.7 for Rails, especially given that Ruby is broken up into
several packages the way it is.
I don’t install v.1.8.7 yet because of it’s not as “stable” as v.
1.8.6. My guide is the version of the One-Click Installer for
Windows… Mostly. I saw they have the 1.8.6-27 Release Candidate 1
with the latest patchlevel of Ruby.
Even Ruby Enterprise Edition stick to v.1.8.6. The latest version was
released in August 10th, meaning they have the latest patchlevel.
While the companies and project don’t make the jump to v.1.8.7, I
won’t either.
I’m also eager to test REE as someone told me on another thread, but
I’m already stuck to the original Ruby despite its benefits with
Passenger. Maybe I’ll test it on my computer to see if it’s worth it
on my job.
Tomorrow I’ll post my opinion of what happened with the installation
of Ruby v.1.8.6-p287.
Is there general consensus on the stability of 1.8.7pXXX with Rails?
Anyone running it in large-scale production?
I think we should pretend this release never existed at all
I agree entirely.
The OP, who is a Rails user, wanted to upgrade to 1.8.6p287 (bad idea
IMO). Some people were giving advice to upgrade to 1.8.7pXXX (which is
an even worse idea IMO, but I wanted to check for other people’s
opinions)
I’ve been avoiding 1.8.7 entirely, since it seems to give the worst of
all worlds: a bunch of features imported from 1.9, which I don’t want,
yet not sufficiently widely used and tested to have shaken out the bugs.
But even the 1.8.6 branch isn’t a stable production branch any more; so
we are left with running 1.8.6p114.xyz where .xyz is some distro’s
bundle of security patches
and concentrate in
getting 1.9 out…
That I can wait for too. Last I heard the feature set hadn’t been
frozen, in which case library authors have a moving target to chase. I
stand to be corrected though.
Also, I have my fingers crossed that the “-> args { meth }” lambda
syntax will be removed before then :-{
The OP, who is a Rails user, wanted to upgrade to 1.8.6p287 (bad idea
IMO). Some people were giving advice to upgrade to 1.8.7pXXX (which is
an even worse idea IMO, but I wanted to check for other people’s
opinions)
Debian jumping to 1.8.7 is probably the wrong move. Not only there are
a few things that would break if you run them in 1.8.7.
Should you start writing your code on 1.8.7 you might use methods that
do not exist in the usual setups with ruby 1.8.5 or 1.8.6.
While 1.8.7 is an interesting experiment I do not really see much use
for that release for now.
I’ve been avoiding 1.8.7 entirely, since it seems to give the worst of
all worlds: a bunch of features imported from 1.9, which I don’t want,
yet not sufficiently widely used and tested to have shaken out the bugs.
But even the 1.8.6 branch isn’t a stable production branch any more; so
we are left with running 1.8.6p114.xyz where .xyz is some distro’s
bundle of security patches
While the security release just after the vulnerability announcement
was rushed a lot of testing was done before the 1.8.6 p287 release.
I suggest this release if you have to install something that’s not
packaged for your system.
This is also what the Windows installers use.
On Debian (and with package managers in general) it is non-trivial to
install a piece of software so that it seamlessly integrates with the
rest. The best way is to install addons (such as a different Ruby
version) separately in /opt/ or /usr/local unless you
have good knowledge of the way the related software is packaged.
Is there general consensus on the stability of 1.8.7pXXX with Rails?
Anyone running it in large-scale production?
I think we should pretend this release never existed at all
I agree entirely.
Sorry to Matz and ruby-core, but Ruby 1.8.7 is a failed experiment.
I really wish they would just retire the release and move forward with
a 1.8.6-base Ruby 1.8.8, and focus the rest of the remaining energy on
1.9.1
we are left with running 1.8.6p114.xyz where .xyz is some distro’s
bundle of security patches
p287 seems to work. It’s the first one since 114 that hasn’t caused
problems for me. Have you had issues with it?
Is there general consensus on the stability of 1.8.7pXXX with Rails?
Anyone running it in large-scale production?
1.8.7 backports a number of new features from 1.9, which concerns me
somewhat, but my biggest concern is how well it’s been tested with
Rails.
Jeremy K. has been monitoring and fixing things in that area, I
believe. He said on rails-core:
Rails 2.1 […] is fully 1.8.7 compatible (1.8.7 backports a lot of
stuff from 1.9, breaking older apps).
I recommend staying on 1.8.6 for all pre-2.1 Rails apps.
I myself do not use 1.8.7 for anything. I’ve reluctantly concluded, as
others have said here, that’s it not a useful release. It’s too
different from 1.8.6, and I don’t believe there’s a need for a 1.9-ish
1.8 release. I know the rationale, as expressed by Matz, is that it is
supposed to help with the transition to 1.9, but I personally don’t
feel the need for a transition version.
I’m here to inform all of you that my installation of the latest
version of Ruby 1.8.6, doing all the required test to confirm its
integrity after that, took over the previous one, meaning it replaced
all the files. This just means one word: SUCCESS!!!
Works perfectly even with Rails apps.
After this and when I begin the next phase of my project, I think I
can stick with 1.8.6… for a long time.
If you were only downloading from ftp.ruby-lang.org you wouldn’t find
it. You have to know about this vulnerability and search for the patch
on the website.
However, credit to the team for providing a patch rather than suggesting
users pick up all changes to the tip of the 1.8.6 branch.
