On Wednesday, June 24, 2015 at 9:03:15 AM UTC-5, miguel wrote: > > On Wed, Jun 24, 2015 at 12:26 AM, Jason Slagle <rais...@tacorp.net > <javascript:>> wrote: >
Open source users will always rely on a third party for security > patches anyway. Every single vendor, named CentOS, Debian and Ubuntu > drops the ball from time to time. Go and look around about the OpenSSL > problems Debian had, and the long period CentOS users were completely > in the dark for security patches. > > "Always" is a bit strong, but yes, it is typical these days to rely on third-party packagers for updates of all kinds, including security patches. No one is ever locked in to that, however. An AIO package does make it harder to apply upstream patches, though, and as the number of upstreams contributing to a single package increases, either the frequency of package updates must soar or the (average) lag between patch release and package update must rise. Moreover, the concern about PL's commitment over time should not be discounted. PL implements a pretty aggressive development and release cycle, and having many simultaneously supported versions will have an additional combinatorial effect on them. Historically, they have supported their software for relatively short periods as many enterprises account things, and once a product goes out of support, you can no longer expect updates from PL for *any* of the pieces. > > A related concern comes with companies with infosec departments that > have > > to bless things. I get Ruby 2.1.0 blessed, but then the bundled ruby > gets > > updated to 2.1.1. Now there are a lot more compliance hoops to jump > > through. > > > > One of the tradeoffs of using the AIO is to be able to move faster, to > get more done, instead of having to be limited by the least common > denominator. I'm sorry, I don't follow that logic at all. I can see the vague outlines of an argument along those lines about AIO on-disk layout and vendored components, but that's not what we're talking about. > Companies with infosec departments that have to bless > things, IMHO, that is their problem. Don't want to fight the > bureaucracy? Buy the support and outsource the responsibility. > > That's a rather cavalier attitude, not to mention missing the point. Even companies that pay for support may still have a requirement for the software to be blessed. That you personally have low regard for such requirements does not make them irrelevant to the discussion. > > In the end, a lot of it comes down to it “not being the unix way”. I > have > > many of the same arguments and dislikes against systemd. I have no > issue > > with the AIO installer, and in fact might use it on some older > > centos/rhel5 hosts where getting modern ruby is hard. My heartburn > comes > > from it being the only REAL way to install these packages starting with > > version 4. I’d much prefer you also support a more traditional > > metapackage approach for the operating systems that support it. > > > > The Unix way? Come on. Lets get rid of packaging then. I'm 34 and the > more senior people I've spoken told me that back in the old days they > downloaded the source code and compile it, on every machine, with that > nostalgia look in the eyes. > Yes, I have no intention of going there. Packaging is one of the significant advances of the last 30 years or so. That's why there are so many packaging systems. As for "the UNIX way", UNIX architecture and tradition revolves around providing many small(ish), independent components that can be combined in useful -- and often unforeseen -- ways. To some extent, AIO packaging indeed does run against that, and to that extent I agree with Jason. > > I think it is counter productive to stick with the metapackage > approach when there is going be a burden to maintain some operating > systems in one way, and some in another way. > That is certainly a consideration for *PuppetLabs*, and it seems clear that they have taken it to heart. I am by no means convinced, however, that it would be harder to following the metapackage approach for those packaging systems that support it than not to do so. Any way around you need different packages for different systems. No matter what, it is not a consideration that matters *to me*, nor, I suspect, to most other users. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/16be4a74-57db-4e0e-a2c4-2657a9922e13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
