Jira (PUP-2182) Package resource not working as expected in 3.5.0

[Kylo Ginsberg (JIRA)]

Title: Message Title

Kylo Ginsberg commented on an issue   Re: Package resource not working as expected in 3.5.0 Sorry for the delay, catching back up. I agree that it is most intuitive if the yum provider behavior matches yum behavior, and the support for virtual packages was a long-requested feature in puppet. My concern with #3 is that future generations of puppet users will forever need to set the `allow_virtual` flag to get the intuitive behavior, adding a source of confusion. So, two thoughts: 1) How widespread is the idiom of package { "old": ensure => absent}; package { "new": ensure => present} and is it readily addressed by, say, making the first resource conditioned on a fact like operatingsystemrelease? That is the idiom that tripped 3 of the scenarios above (though not the jre case). 2) If we do end up needing a new parameter should it be opt-out rather than opt-in, e.g. 'disable_virtual' rather than 'enable_virtual'? This would allow the default behavior to be the intuitive behavior Add Comment   Puppet / PUP-2182 Package resource not working as expected in 3.5.0 One of my modules has the following code: {code} package { 'inetd': ensure => absent; } {code} On the next Puppet run, Puppet tries to remove the xinetd package (debug output): {code} Debug: Executing '/bin/rpm -q inetd --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n' Debug: Executing '/bin/rpm -q i... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.