We're not going to ship deb and rpm metapackages, to address the last points on the thread. We _will_ make it as easy as possible to build AIO with different combinations of component versions so you can compose your own but still retain up- and down-grade compatibility with PL supplied packages. I'm sorry you and John aren't convinced by the all-in-one plan; I see your point and totally agree that as an advanced Linux+FOSS Puppet user, it's not the optimum solution.
--eric0 On Dec 7, 2014, at 3:33 PM, 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. > > > > > -- > 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. Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/C2ACFBC3-E161-4508-9250-96E53043E469%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
