Before I reply to you, I wanted to let you know that I am grateful to you, Bohuslav,
Lutterkort, Jeroen, Mamoru and Mo (and others) for all the Fedora/RH Ruby RPM/packaging. I
have my own Koji cooker where I am currently building 165 packages for RHEL5 to support a
suite of Rails applications and I'd be solving my problem very differently if you guys
I only jumped in because the OP is having bundler issues and I know for a fact that
bundler is broken as packaged by Fedora.
From: ruby-sig-bounces(a)lists.fedoraproject.org [mailto:ruby-sig-
bounces(a)lists.fedoraproject.org] On Behalf Of Vít Ondruch
Sent: Friday, September 20, 2013 7:27 AM
Subject: Re: regin LoadError with rack-mount and backports when trying
to run unicorn
Dne 18.9.2013 19:26, Allen Hewes napsal(a):
> Hi Vit,
> I am not sure that this is related but, the bundler as "built"
(packaged) in Fedora has a "bug" in it. "lib/bundler/vendor" should
have never been removed .
It has to be removed due to Fedora policies.
I understand the polices here. I really do. But when policies produce a broken package,
wouldn't a better decision be to NOT produce that package? Since it shows up in a yum
command, probably everyone thinks that package is sane and works as expected, at least I
did. I can't speak for the OP.
> Well, if it was removed, someone should have modified bundler to load
the thor/net-http-persistent gem via a require/relative_require. But
that's not what happened.
There is no way how to do it, since you don't know where to find
thor/net-http-persistent on the system. If Bundler had used original
RubyGems require, it would be OK, but they opted to use their custom
loader. That is the biggest fail in Bundler design (if we can speak of
desing, since Bundler is unfortunately just pile of workarounds).
I toyed with producing RPMs like rubygem-bundler-thor /
rubygem-bundler-net-http-persistent and modifying the
vendored_persistent.rb/vendored_thor.rb files. I was thinking of satisfying Fedora's
policies so that I could give my work to Fedora. I never took this past thinking about
I also toyed (made local changes to bundler) with changing bundler to load them ala
require/relative_require but arrived at the same place you describe; the bundler guys are
doing their level best to make a mess out of $./$LOAD_PATH. That combined with their
rubygems "emulation", I gave up and just decided to produce my own version of
rubygem-bundler that didn't wipe out "lib/bundler/vendor". After a few days,
I gave up on this idea. I MUST have a working bundler.
Also, you won't hear me talking up bundler. I can't stand the darn thing and
it's not a very good solution to a hard problem. Plainly, I hate it. The problem
bundler solves should be solved in rubygems or a rubygems plugin.
I can't deploy my rails applications WITHOUT bundler.
> As a matter of fact, bundler tells you NOT to use a "gem" installed
version of thor , as that "may cause Bundler to malfunction in
Yes, they opted for bundling instead of proper design. Unfortunately,
Bundler upstream was never open to any of our suggestions towards
packaging and easier collaboration with distributions. They live in
(MacOS X) world and they can't imagine, that somebody might use
> When I looked into this for my needs, I determined that a patch would
be required to make bundler happy if the "lib/bundler/vendor" directory
was removed. You'd have to modify vendored_thor.rb and
Could you share your patch with us, please?
I solved my issue by importing the rubygem-bundler packaging source and commenting out the
removal of "lib/bundler/vendor". Like I mentioned earlier, I have my own Koji
setup and I produce a yum repo "overlay" ontop of RHEL5 for my needs. So my
version of rubygem-bundler does work for my needs.
> Usage of many of the bundler arguments (--with/without, etc) causes
errors when "lib/bundler/vendor" has been removed.
Some examples? Bugzillas?
I created a BZ report https://bugzilla.redhat.com/show_bug.cgi?id=1010406
ruby-sig mailing list
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents
linked to this email, are intended for the addressee and may contain information that is
privileged, confidential, proprietary, or otherwise protected by law. Any dissemination,
distribution, or copying is prohibited. This notice serves as a confidentiality marking
for the purpose of any confidentiality or nondisclosure agreement. If you have received
this communication in error, please contact the original sender.