On Mon, Aug 6, 2012 at 10:16 AM, Ken Barber <[email protected]> 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. > ken. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" 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-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
