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 <[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. > > > > > -- > 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. Eric Sorenson - [email protected] - 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 [email protected]. 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.
