----- Original Message ----- > From: "Michael Stahnke" <stah...@puppetlabs.com> > To: puppet-dev@googlegroups.com > Sent: Monday, August 6, 2012 11:05:15 AM > Subject: Re: [Puppet-dev] Bundling minitar for puppet module face > > On Mon, Aug 6, 2012 at 10:16 AM, Ken Barber <k...@puppetlabs.com> > wrote: > > Hi puppet-dev, > > > > TL;DR - I'm thinking about shipping minitar with puppet to make > > module > > install/build work consistently (and to ease development) (see: > > http://projects.puppetlabs.com/issues/15841) and wanted some > > feedback > > > > ------ > > > > So in case you don't already know - the puppet module face utilises > > system tar and gzip to unpack and pack modules. This has been > > troublesome for me - and I anticipate it will continue to cause > > trouble. > > > > Case in point - I was pondering the following ticket: > > > > http://projects.puppetlabs.com/issues/14333 > > > > And how one would implement it in a tar implementation agnostic > > way. > > The problem is, every tar implementation (bsd, sun, gnu) have > > different switches to support this requirement. I wanted however to > > zoom out and propose that we instead start bundling our own version > > of > > archive-tar-minitar with Puppet for this very use case, plus for > > some > > other reasons: > > > > https://github.com/halostatue/minitar > > https://rubygems.org/gems/archive-tar-minitar > > > > So as another example of hassle - I recently I had some fun getting > > Sun tar working with the puppet module face, and found that the > > discrepancies created issues - in the end I just supported gnu tar, > > but this puts a dependency now on the need for 'gtar' on the host > > before the tool will work. > > > > Another example - to get windows working we could either ship tar, > > or > > do something like I'm proposing. Again, using our own tool means > > there > > is much less special casing for platform and tar implementation. > > > > What do people think about this? Do you think there is a better way > > to > > get agnostic support for tar? All comments welcome ... > > > > If bundling is acceptable - how would you like to see it done? > > Today - > > I'm considering moving it into the Puppet:: namespace and > > effectively > > forking it like we have done for other tools. Since minitar hasn't > > changed for 4 years (last release was 2008) I don't anticipate a > > lot > > of frequent changes (perhaps ongoing Ruby version support?). > > > > I've created a ticket to track this btw and made some notes on why > > I'm > > thinking this way: > > > > http://projects.puppetlabs.com/issues/15841 > > > > If you're going to bundle it, I'd rather us not fork it. Keep it in > its own directory, and allow distros to rm -rf it, and add mini-tar > as > a dependency. > > http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries pretty > much sums up my thoughts on bundled libraries in general. > Mcollective > is actually a decent example of bundling that is easily undone and > works for package maintainers. >
+1, we discussed this in the past and everyone more or less decided mco is wrong how its done but really, its best :) the thing I need to do better in mco is write a package maintainers guide to make it clear to people how to undo the bundling as there's been some mistakes made where people just werent aware we did it this way but on the whole how mco does it worked out really well for us. The guide should be in the top level or in the top level README or something -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
