This is better than what is currently being used, but I'm strongly in the AIO idea to be stupid. Split it into multiple packages and use proper dependencies like every other sane packaging system has done for a long, long time.
If all you do is bump the version of facter, then only have me download and install the meta package that depends on the new facter, and the new facter package, not everything. <rant> I'm only planning on using AIO packages on the server side and stick with the gem packages on the client side. With multiple client types (multiple versions of OS X, multiple versions and distributions of Linux, various architectures), I know the gem packages can be handled the same way on all of them. When I'm adding a node to the network, I like being able to do type "gem install puppet", set up the key, then let puppet take care of the rest. With the AIO packages, I have to start out doing puppets job and add a repo and refresh my package manager before I can get to the step of installing puppet. Not to mention praying that the platform is even supported by the AIO packages. </rant> On Wednesday, June 17, 2015 at 12:12:31 PM UTC-7, Eric Sorenson wrote: > > On Thu, 7 May 2015, jcf wrote: > > >> > >> I don't think that reflects a firm grasp of the nature of the problem. > The issue is that the "new thing" here is not the thing that the package's > version number should be describing in the first place. I don't care about > the newness of AIO layout and packaging, and I don't expect many others > will either. People don't install Puppet for its packaging. I do care > about the versions of various components of the system, but not everyone > will, and anyway, we have already established that an AIO package's version > number is not a good vehicle for communicating information about versions > of auxilliary components. Focus on what's important. To your audience. > > > > I am also pretty baffled that this is considered hard, or even a matter > for debate. Principle of Least Surprise, or just have the contents match > the tin. > > FWIW I find this argument pretty compelling and would like to advance the > version number of the next release of puppet-agent to '4.something'. > > Our current thinking is that this will be a matched to the puppet version, > with an extra digit on the end of the version number that indicates > component > revisions other than Puppet itself. > > So specifically, the next release will be puppet-agent-4.2.0.0; a > hypothetical > rev to include a not-very-hypothetical openssl update would be included in > a > puppet-agent-4.2.0.1 package. > > (We can't use the release field as suggested up-thread, because some > packaging > systems don't view numbers not part of the 'version' field to be an > upgrade.) > > Does that align more closely with the least-surprising thing, to you? > > Eric Sorenson - [email protected] <javascript:> - freenode > #puppet: eric0 > puppet platform // coffee // techno // bicycles > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ecec4c5e-3b0b-41f5-a126-3cdc08716369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
