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.
