* Sam Ruby <rubys@intertwingly.net> [130602 18:31]:
> On 06/02/2013 11:55 AM, Praveen A wrote:
> >
> >We should not be using bundler or rubygems at all. So create a quilt
> >patch and comment out all usage of bundler and rubygems like require
> >'rubygems', require 'bundler/setup', Bundler.require etc.
>
> Forgive me, but this seems like advice that is conflicting with the
> input from Christian. And if taken literally, would fundamentally
> change how Rails works. Permit me to explain.
Well - I have no preference either way; with my bundler package
maintainer hat on, I must say that the presence of bundler in the
archive does not change Ruby Extras packaging policy or anything.
In the end, the Rails package maintainers should have their say on
this (I haven't looked at how rails-3.2 works, but it _does_ Depend:
bundler).
> From what I can see, there is a problem with either how Rails is
> packaged, or with bundler and/or with rubygems-integration. And it
> makes sense to resolve that problem before determining how best to
> proceed with shoulda-matchers.
From what I can see in the shoulda-matchers tests, the test
application has a Gemfile.lock, which tries to pull in a version of
"i18n" that is not in the Debian archive.
For your tests to succeed, you'll need to Build-Depend on ruby-i18n,
and I *think* remove the Gemfile.lock.
My current stance on shipping packages that use Bundler to manage
their dependencies, is, that one cannot ever ship a Gemfile.lock in
a Debian package and expect things to work.
Again: I have no say on Ruby Extras packaging policy (which to my
understanding forbids/discourages depending on rubygems, and by extension
bundler) -- but this is what theoretically should make things work.
> - Sam Ruby
C.
--
Christian Hofstaedtler | design, deploy, scale
http://christian.hofstaedtler.name/ | phone +43 720 699846
Attachment:
signature.asc
Description: Digital signature