F20: Puppet depchain pulls in Java

[Michael Stahnke]

On Sat, Jan 18, 2014 at 5:55 AM, Mo Morsi <mmorsi at redhat.com> wrote:

>  On 01/18/2014 01:40 AM, Michael Stahnke wrote:
>
> On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram <metherid at gmail.com> <metherid at gmail.com> 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 jruby
>
>  So 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.
>
>
> Could you elaborate on what the difficulty is? Just curious as to what
> issues there are.
>
I've had issues in the past with Ruby pick when it was first being
developed. I know some apps (and possibly some gems) expected env ruby to
eval to a ruby and not ruby-pick shell helpers. That may not be the case
any more, as I haven't run into that in a while. (Though I don't always use
the Fedora ruby any more either).

I remember having to unpatch bundler to do what I wanted. Now, I basically
hate bundler, but when it works differently on Fedora than it does on other
platforms that only makes it worse.

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.
>
> Yes, bundler is counter to the the philosophy. So is golang. Sadly, people
spend person-years redoing this work then with statically linked or bundled
stuff. I don't love it at all, but I do see big upticks in all-in-one
packages (omnibus, fpm, etc) in the community -- at least around
configuration/cloud automation. And they all complain about distro
packaging because of maintainers modifying upstream behavior. This is
normally a larger issue on other distros (not Fedora), but we are not
immune to it.


>  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-mri
>
>  I 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?
>

We (Puppet Labs) tries to keep test passing in Jruby, but there a few bugs.
I think master side it works ok, unless you have providers that use C
extension gems. Agent side, we do no testing of running on Jruby. We'll be
doing much more with Jruby master side in the future, so those bugs (if
they haven't already been) should be worked out soon.

We don't test rubinius, but we have a few fans of it here. I'd be curious
if our spec tests pass on that. I'd be happy to look into those details
more, but we should probably move the conversation to a different thread.

>
>    -Mo
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140121/81dd0052/attachment.html>