Hi All, I'm curious as to what decisions (if any) have been made here.
Thanks, Trevor On Mon, Nov 24, 2014 at 12:40 PM, Trevor Vaughan <[email protected]> wrote: > I'm in 100% agreement with John here. > > Right now, I have a forked Hiera that I'm using based off of some patches > that I have PRs in for. Once this gets resolved, I'll merge everything back > to the mainline, but I *must* have the ability to deviate when necessary > for the best results of my users. > > As with John, if this is not the case, I'll just end up re-packaging > everything myself and forgo the AIO packages (and not be thrilled about it). > > Thanks, > > Trevor > > On Mon, Nov 24, 2014 at 11:12 AM, John Bollinger < > [email protected]> wrote: > >> >> >> On Friday, November 21, 2014 2:47:05 PM UTC-6, Eric Sorenson wrote: >> >> >> >>> 5 - Why not use a metapackage which has no content of its own, but has >>> requirements on specific versions of the other 'real' packages that contain >>> the actual programs? >>> • Avoiding a coordinated major version ship across all projects… >>> We're changing the layout on the filesystem (moving to opt) for a few >>> reasons, including shipping our own stack without conflicting with system >>> libraries. >> >> >> >> Not buying it. An AIO package does not inherently avoid these sorts of >> problems (i.e. what if I have both 'facter' and 'puppet-aio' packages >> installed at the same time?), and a metapackage approach is not inherently >> any more susceptible to them (it's all about which packages are managed). >> >> >> • We want to simplify the endpoint install experience for users. >>> A single endpoint puppet agent package is arguably among the simplest >>> possible deployment mechanisms. >>> >> >> >> Yay for simple installation. A metapackage achieves that, too. >> >> >> >>> • Meta-package only solves the problem for agents with a package >>> manager that can do remote dependency resolution. We want the install >>> experience for agents to be excellent/seamless regardless of the platform >>> you are running, and be the same experience across the board. Users >>> installing a Solaris 10 agent package shouldn’t have a different experience >>> than users installing a Debian 7 agent package. >> >> >> >> So? You are committed to separate native packaging for a wide variety of >> systems anyway. Why not make use of the features of those systems that >> have more capable package managers? >> >> I really, really dislike AIO packages. In fact, I tend to break them up >> when I can. They do confer a greater level of control on packagers, but >> along with that comes considerably more responsibility and exposure, and >> considerably less user flexibility. If anything needs changing in any >> component, the whole AIO needs to be updated. Any flaw or vulnerability in >> any component is a flaw in the whole AIO. The more components you bundle >> together, the worse it is, and it is particularly bad when you bundle >> third-party components. >> >> It just doesn't have to be that way on systems that can support >> metapackages. You can have your cake and eat it too: a metapackage >> provides for easy installation and update, and done right it provides for >> ensuring that a given installation has a tested and approved combination of >> components, but you still have the flexibility of managing components >> individually (possibly requiring the removing the metapackage but retaiing >> the component packages). >> >> In the end, you'll of course do what you think best. If it ends up being >> AIO packages across the board, then I simply won't use your packages. What >> a shame. >> >> >> John >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/50155310-cda5-4384-b7d8-45ebe729449c%40googlegroups.com >> <https://groups.google.com/d/msgid/puppet-dev/50155310-cda5-4384-b7d8-45ebe729449c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] > > -- This account not approved for unencrypted proprietary information -- > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUSjRqZUv29Ofu%3DpiHz3Y2Nk9Lwu3oT1qXDf53bCnbchg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
