Hi Garrett,

thx for the thoughts. I am basically doing as you suggest. Whenever possible I 
hold to latest versions of package maintainers

But Debian often comes with old versions of PHP which poses a problem. So I 
tend to use sury repositories to install newer but well tested packages of PHP. 
This repository offers several versions of PHP, at the moment mostly 7.3 and 
7.4. Common software packages now tend to switch to PHP 7.4 so sometime you 
sort of should follow that move to keep up to date.
Debian 9 came with PHP 7.0 I think (7.1 the most), which should not be used any 
more, but Debian 9 is still actively updated.

So whether I am on dev, preproduction, staging or live. If I do go this way for 
PHP, I will have to decide which version of PHP to use. And when I decide to 
switch the version, I can easily have Puppet do that, but the old versions keep 
installed and will be updated as well, which is undesirable.

Regards
Jochen

> Am 12.10.2020 um 19:07 schrieb Garrett Honeycutt <g...@garretthoneycutt.com>:
> 
> On 10/12/20 5:10 AM, jochen....@gmail.com <http://gmail.com/> wrote:
>> Hi all,
>> 
>> I posted a question on Stackoverflow before the weekend, but no
>> responses and not many views yet, unfortunately. So please forgive me
>> asking this again here. refactor ensure_packages to switch version of
>> installed packages https://stackoverflow.com/q/64284862/13088564?sem=2
>> 
>> 
>> I am successfully installing several PHP modules by version with puppet
>> on Debian linux like this:
>> 
>> $php_version = '7.3' 
>> ensure_packages([ 
>>     "php$php_version-xml", 
>>      "php$php_version-zip", 
>>      "php$php_version-curl", 
>>      "php$php_version-mbstring", 
>>      "libapache2-mod-php$php_version",
>>  ], 
>>  { 'ensure' => 'present', } )
>> 
>> now I want to prepare for an update from PHP 7.3 to 7.4. This basically
>> works, but the 7.3 packages stay installed. I would like to adapt the
>> code to remove the old packages. I am looking for a way to reuse the
>> list of packages of modules for uninstalling.
>> 
>> I am thinking of a signature like this
>> 
>> class profile::software::apache (
>>      $php_version = '7.4',
>>      $php_remove = ['7.0‘, ‘7.3']
>>     , #... 
>> ) {
>> 
>> $myPackages = [
>>      "php$php_version-xml",
>>      "php$php_version-zip",
>>      "php$php_version-curl",
>>      "php$php_version-mbstring",
>>      "libapache2-mod-php$php_version",
>>  ] 
>>  
>> ensure_packages($myPackages, {
>>      'ensure' => 'present', 
>>  } ) 
>> 
>>  $php_remove.each | String $php_version | { 
>>      ensure_packages($myPackages,
>>      { 
>>           'ensure' => 'absent', 
>>      }  )
>>  }
>>  }
>> 
>> Is there a way to solve this?
>> 
>> thx
>> 
>> -- 
>> 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
>> <mailto:puppet-users+unsubscr...@googlegroups.com 
>> <mailto:puppet-users+unsubscr...@googlegroups.com>>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/64abfa9c-5b7a-4aac-8a78-8e5152e8d66cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/64abfa9c-5b7a-4aac-8a78-8e5152e8d66cn%40googlegroups.com>
>> <https://groups.google.com/d/msgid/puppet-users/64abfa9c-5b7a-4aac-8a78-8e5152e8d66cn%40googlegroups.com?utm_medium=email&utm_source=footer
>>  
>> <https://groups.google.com/d/msgid/puppet-users/64abfa9c-5b7a-4aac-8a78-8e5152e8d66cn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> 
> Hi Jochen,
> 
> Can Puppet handle this, yes! Should it, absolutely not. As you have seen
> from the posts you are going to quickly have a huge list of things you
> do not want on your system which becomes hard to manage. Instead of
> that, suggest you manage what packages are available in your
> repositories. You can tell puppet to install php-whatever and not
> specify 7.3 vs 7.4 vs 7.4.2, etc. You could have systems in different
> environments use different paths in your repo definitions such that you
> can test new packages in a pre-production environment and then update
> the URL's in other environments. You will end up with a much more
> reliable change management process for patching than attempting to track
> all the versions in Puppet.
> 
> Best regards,
> -g
> 
> 
> -- 
> Garrett Honeycutt
> 
> -- 
> 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 
> <mailto:puppet-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/eb2655bd-b4ee-d487-e646-1ad2ad537120%40garretthoneycutt.com
>  
> <https://groups.google.com/d/msgid/puppet-users/eb2655bd-b4ee-d487-e646-1ad2ad537120%40garretthoneycutt.com>.

-- 
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/7A0D16FD-B2F8-46A2-8978-24C745684973%40gmail.com.

Reply via email to