<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/23/2011 04:31 AM, Vít Ondruch wrote:
<blockquote cite="mid:4EF44A55.4020708@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Dne 22.12.2011 17:19, Scott Seago napsal(a):
<blockquote cite="mid:4EF358A9.5020305@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
<blockquote cite="mid:4EF33A29.1040405@redhat.com" type="cite">
<blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
<pre wrap="">- In the Rubygems section:
"For every dependency on a Gem named <code>gemdep</code>, the package must contain a <code>Requires</code> on <code>rubygem(%{gemdep})</code> with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora</pre>
</blockquote>
<br>
You are right. We should not be as strict. Actually, I believe
that we should not use version unless necessary. We will try
to polish this formulation according to your suggestion.<br>
</blockquote>
Actually, we need to be very careful here. We've been bitten in
the past by creating RPMs with deps that don't strictly follow
the gem deps, since you then have a gem installed that, strictly
speaking, doesn't meet its gem dep requirements. If you end up
using bundler for something, it's going to complain. We had a
big problem with this when we had an RPM for which the
underlying gem required rspec (2.0+), but we required the rspec
sub-packages instead.<br>
<br>
Scott<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ruby-sig mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ruby-sig@lists.fedoraproject.org">ruby-sig@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/ruby-sig">https://admin.fedoraproject.org/mailman/listinfo/ruby-sig</a></pre>
</blockquote>
<br>
Scott,<br>
<br>
I understand your point, unfortunately there is not good solution.
In Fedora, if you are *not* developer, then you have always one
set of packages which should work together and this should be
ensured by its packagers, i.e. the packagers in Fedora should
replace the Bundler in Ruby world. I know, its probably to much
should but that is how it works. Let me give you one example I
remember:<br>
<br>
If you are using Rails 3, their dependency says that they needs
Rack ~> 1.3. However, we had in Fedora just Rack 1.1 and
unresponsive maintainer. So how would you solve it? We chosen to
relax the Rails dependency to ~> Rack 1.1 and everything worked
just fine. However, if you used your Gemfile.lock, it obviously
either did not work on other platforms or did not worked for
Fedora. So in this case you can either:<br>
<br>
1) Do not use Bundler.<br>
2) Provide more Gemfile.lock, for each Fedora version etc.<br>
<br>
Generally I am fan of 1) and I would say we are using it quite
often already. There is plenty of gems which are trying to use
Bundler to execute their test suite and the best solution IMO is
just to remove "require 'bundler/setup'" and you don't rely on the
Bundler anymore.<br>
<br>
Btw the problem with RSpec might be of two natures. Either you
tried to use Gemfile.lock which was not specific for the Fedora
you used or it was bug in packaging, i.e. the packager specified
some RPM requirements, but forgot to update the .gemspec to proper
versions. Speaking about that, we should note how to do that.<br>
<br>
<br>
</blockquote>
Yes, the issue with rspec was the second one. The RPM deps were
modified from the gemspec, but the gem itself was left untouched.<br>
<br>
Scott<br>
<br>
<br>
</body>
</html>