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 -- -- 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%2BFoXj_X1w7Uy%3D_bdsZYjduFp7vaPYMoPAEy0dcfm%2B%3DobdvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
