Issue #9383 has been updated by R.I. Pienaar.
Yes, its conceivable gems can be used to ship library files - thats what its for. This however is not the problem with gems. The problem with gems for shipping programs is that it has no concept of things like creating an /etc skeleton or a /var one. Or of adding rc scripts. <pre> # gem install puppet # ls /etc/init.d/puppet* zsh: no matches found: /etc/init.d/puppet* </pre> This isnt an installed application it's simply a source of user frustration. To address these issues with gems not being a package system for general use of applications puppet will on first start as root create the /etc and /var skeletons it needs. Generally for puppet this is easy cos it has all these providers and cross platform stuff built in. But again for users this is a constant source of frustration, see the very frequent questions from users like 'puppet is replacing my /etc/puppet symlink' and others of the same theme. A correctly installed application like mcollective would prepare the operating system to a working level, this includes rc scripts, config files etc. This is not possible with gems and I wouldn't consider the end result as 'working' ---------------------------------------- Feature #9383: Create an mcollective-client gem https://projects.puppetlabs.com/issues/9383 Author: Zachary Stevens Status: Accepted Priority: Normal Assignee: Category: Packaging Target version: Keywords: Branch: Affected mCollective version: When installing mcollective via operating system packages, the ruby library is only available to clients using the system ruby. It should be possible to write client applications using an alternative ruby, while still sharing the configuration and plugins from the system mcollective install. Discussion on #mcollective: < zts> I'm currently installing mcollective using the RPMs, which was cool until I started needing to write clients that run under a different ruby to the system one < zts> it feels like what I want is the mcollective client bits as a gem that I can install into different rubies, but I'm prepared to hear that I'm wrong < zts> what's the best approach to dealing with this requirement? < Volcane> could potentially do the client stuff as a gem - but not appropriate for the server bits < Volcane> still leaves the problem of distributing your applications, security plugins etc < Volcane> since those cant really go into gems easily I'd think < zts> yeah, I'm happy managing configurations and plugins at the system level, and the behaviour I'd want is for all clients to share the same configuration, plugins etc < Volcane> nods < Volcane> yeah a gem for the client isnt a bad idea < chrisa2> a client gem would be very useful where you're embedding a client into an app that uses bundler < chrisa2> because you can express the dependency in the usual way, rather than relying on a system mcollective, or just vendoring the stuff in the app < Volcane> make a feature request pls < Volcane> might be awkward matching up gem versions and plugins etc but i guess everything has some cost -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
