On Thu, Mar 27, 2014 at 12:22 PM, Daniele Sluijters < daniele.sluijt...@gmail.com> wrote:
> Hey, > > As far as package is concerned I prefer Adrien's suggestion of ensure => > held, version => 0.4. This is entirely personal but I think ensure is a > good place to model the 'state' of a package and when it comes to apt that > state is either held, removed, purged or installed. I would go as far as to > say that 'ensure => latest' should not exist, it should be 'ensure => > installed with version => latest'. > > If I think about it in English I'd say "I want the latest version of this > package installed" which is why the mapping "version => latest" makes more > sense to me as does an 'ensure => installed'. I would also say something > like "I want nginx held at 1.4.7" which fairly easily translates to "ensure > => held, version => 1.4.7". This specific use-case of holding a version > isn't even possible with the current package type because of how the apt > provider works, it will hold the current installed version, you can't > request it to install a specific version and hold that one except for > messing with apt policies. > > I have no idea how this translates to other package managers though. > > I think the crux of the matter is how well the proposal would translate to other package managers. I think that the proposed separation of ensure and version makes sense, but it also opens up a few edge cases that having all of it in ensure doesn't. For instance, what should be expected to happen if the package is "ensure => held, version => 1.4.3" but version 2.1 is actually installed? I expect the answer is to downgrade to 1.4.3 and do whatever the package manager can do for holding. But is that a universal enough capability? > As far as 'ensure => directory' on a file goes I don't really mind that > syntax, in my mind a directory is just a special file, much like a symlink > is or a socket. A separate directory type might be interesting if it has > extra magical powers that the file type doesn't, like having a flag that > implies `mkdir -p` instead of `mkdir` for example. > > -- > Daniele Sluijters > > On Wednesday, 26 March 2014 19:12:33 UTC+1, Jesse Hathaway wrote: >> >> In my discussion with @adrienthebo on my pull request: >> https://github.com/puppetlabs/puppet/pull/2309 I raised the question of >> what should be the allowable or suggested values for the ensure property? >> >> My pull request separated out the hold state into a separate property: >> >> before: >> >> package { 'foo': >> ensure => held >> } >> >> >> after: >> >> package { 'foo': >> ensure => '0.4', >> hold => false >> } >> >> >> @adrienthebo suggested I separate out the version instead: >> >> package { 'foo': >> ensure => held, >> version => '0.4', >> } >> >> >> @adrienthebo's suggestion is certianly doable, my question is whether the >> puppet community has come to a consensus on what values the ensure property >> should have? >> >> In general my experience has been that adding additional values to ensure >> for resources makes using a resource less intuitive. For instance I find >> the file resource has a confusing interface because of the way it abuses >> the ensure property: >> >> file {'/foo': >> ensure => file, >> } >> >> file {'/foo': >> ensure => directory, >> } >> >> >> I would rather have explicit resources: >> >> directory {'/foo': >> ensure => present >> } >> >> >> What are the communities thoughts? >> >> -Jesse Hathaway >> > -- > 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/feb80058-5a45-46f0-8b05-cb86b54b645c%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/feb80058-5a45-46f0-8b05-cb86b54b645c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco - **http://puppetconf.com <http://puppetconf.com/>* -- 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/CANhgQXsbxw48T4yMsPGptbTk61tfW52q1jNb5C2WdKDCqmX6mg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
