|
On 01/18/2014 01:40 AM, Michael Stahnke
wrote:
On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram <metherid@xxxxxxxxx> wrote:Hi On Fri, Jan 17, 2014 at 9:43 PM, Mo Morsi wrote:Yes as others have mentioned puppet requires ruby(release) which is satisfied by both ruby-mri and jrubySo should it just require ruby-mri? The divergence from the way upstreams handle ruby here is quite difficult to work with. I find ruby-pick and bundler patching to be less fun/friendly than having what I'd expect form upstream. I'm not in love with the way upstream handles/does things, but I don't really understand what happened to the 'upstream first' mantra. Here we (Fedora) just made up their own rules and moved forward. Completely agree that the current Fedora/Ruby integration is not
ideal, it is a work in progress afterall. That being said upstream
Ruby practices and downstream Fedora guidelines do take different
approaches to many various things, eg just the existence of
bundler is counter to Fedora's 'no-vendored-deps' policy. So
compromises will have to be made at some level. We try our best to make everyone happy, providing as much of the
flexibility associated with upstream Ruby practices that we can
while still adhering to Fedora's principles and strategies. Now if
we could install multiple versions of a rubygem rpm via yum,
that'd help us out a bit..... ... which is fine. However yum install puppet should be pulling in only one. Not both. I would say almost everybody would expect that to be ruby-mriI would say exactly everybody, since on jruby there are issues. Didn't know puppet didn't work on JRuby, what about the other
Ruby interpreters such as Rubinius? If MRI is the only supported
solution for Puppet, then yes I'd agree that specific dep should
be there (though am not the package maintainer myself), but if it
can work against multiple backends then why not let the user
decide? -Mo |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
