I was also curious where (and if there was a guess when) to look for nightly builds so I can start testing the decisions made.
Thanks, jl > On Dec 7, 2014, at 16:33, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > > 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 <tvaug...@onyxpoint.com> >> 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 >>> <john.bollin...@stjude.org> 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 puppet-dev+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/50155310-cda5-4384-b7d8-45ebe729449c%40googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvaug...@onyxpoint.com >> >> -- This account not approved for unencrypted proprietary information -- > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- 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 puppet-dev+unsubscr...@googlegroups.com. > 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. -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/69D7C474-E213-4A82-B111-C2621675239D%40infiniteviewtech.com. For more options, visit https://groups.google.com/d/optout.
