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 <[email protected]> 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 <[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. >>> >>> 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. -- 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/69D7C474-E213-4A82-B111-C2621675239D%40infiniteviewtech.com. For more options, visit https://groups.google.com/d/optout.
