<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dne 22.12.2011 18:24, Scott Seago napsal(a):
<blockquote cite="mid:4EF367B3.1090706@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
On 12/22/2011 11:45 AM, Mo Morsi wrote:
<blockquote cite="mid:4EF35E90.1000700@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
On 12/22/2011 11:19 AM, Scott Seago wrote:
<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>
</blockquote>
<br>
Ah good point. Actually now that I think about it the guidelines
could use something to the effect of how to integrate bundler
and other alternative gem-dependency management into all of this
(its been a royal pain up to this point).<br>
<br>
If nothing else, perhaps a guideline stating that if you modify
the gem dependency list in the rpm spec, you must ensure that it
is modified in bundler's Gemfile as well.<br>
<br>
Actually expanding upon this, I'd love to see the work that Jay
did with making bundler usage toggleable in conductor, a more
generic plugin, able to be pulled into any project. Jay any
thoughts on the feasibility of this?<br>
<br>
-Mo<br>
</blockquote>
Well the particular problem wasn't because bundler deps were
mismatched. We were hitting problems because we didn't have all
gems required in the gemspec weren't installed. Basically, if
source isn't commented out in Gemfile, if we have a gem installed
without its deps, bundler will install it (resulting in a gem
_not_ from the fedora repos as a gem RPM in your dep chain. If
source _is_ commented out (which is how we handle bundler for
conductor on fedora -- to keep random different versions of Gems
from being installed) we get errors about required gems not being
available.<br>
<br>
So, this brings us back to if the gemspec requires $foo, then our
RPM had better require rubygem($foo) or we're asking for trouble
down the line.<br>
</blockquote>
<br>
Actually the original discussion was about *versioned* dependencies.
<br>
<br>
However, it is packager's responsibility to provide correct RPM
dependencies. There is a lot of cases when to not follow the default
dependencies for several reasons. You can take Rails as an example
again. We are not closely following the gem dependencies, because
the gem dependencies does not reflect reality. However, it is good
for us to not follow them, because it might simplify our build
process. If that causes troubles, well be it, it's a bug which needs
to be solved. But I take the original gem dependencies just as a
guideline and nothing more.<br>
<br>
One more thing. We have Rawhide where the development should happen.
Rawhide have freeze period when you should polish your packages etc.
Once the Rawhide turns into stable Fedora version, there should not
land any new Feature without good reason. If you want do it, you are
asking yourself more troubles. This approach allows you to focus
just to one version of Fedora, i.e. Rawhide and once it is released,
you don't have any troubles, because you had plenty of time to
polish issues such as wrong dependency.<br>
<br>
<br>
Vit<br>
<br>
<blockquote cite="mid:4EF367B3.1090706@redhat.com" type="cite"> <br>
Scott<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ruby-sig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ruby-sig@lists.fedoraproject.org">ruby-sig@lists.fedoraproject.org</a>
<a 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>
</body>
</html>