Silly question, but what package manager doesn't let you upgrade those two
packages independently but also doesn't update the dependent packages at
the same time?
On Monday, April 18, 2016, J.T. Conklin <j...@acorntoolworks.com> wrote:
> Before we started using puppet at work, we didn't have a systematic
> process to install packages on our servers. As a result, we had servers
> in the same "role" that (unintentionally) had different sets of packages
> installed.
>
> A very common case was that the 64 bit version of a library was
> installed but the corresponding 32 bit version was not. This usually
> wouldn't be detected until one of our users tried to run a 32 bit binary
> that used that library on that particular system.
>
> So we used puppet to bring our systems in line, selecting what packages
> to install based on architecture. For example, in our openssl module,
> we changed:
>
> $package = 'openssl'
>
> to:
>
> if $architecturee == 'x86_64' {
> $package = [ 'openssl.x86_64', 'openssl.i686' ]
> } else {
> $package = 'openssl'
> }
>
> While this worked the first time to install the 32 bit openssl on all 64
> bit machines, it fails when installing/updating to a new openssl version
> (due to security issues, etc. as has been necessary recently) as the yum
> provider attempts to install the 64 and 32 bit packages in the array
> separately when they must be installed simultaneously. I tried changing
> the array to:
>
> $package = [ 'openssl', 'openssl.x86_64', 'openssl.i686' ]
>
> thinking that having the un-suffixed version first would cause both to
> be updated in the common case, and the suffixed versions to install the
> specific 32 or 64 bit version if it's not already installed.
> Unfortunately, this fails the same way.
>
> Now that all our legacy systems have been "fixed", I suppose we could
> drop the package array and go back to the original un-suffixed package
> definition. But if there is a pattern that will work, I'd prefer using
> it instead. Do any of you have a working idiom?
>
> Thanks in advance,
>
> --jtc
>
>
>
> --
> 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 <javascript:;>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/87oa96o0yu.fsf%40wopr.acorntoolworks.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Rob Nelson
rnels...@gmail.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/CAC76iT8_0DHz3%3DMeanfgajkuYu3VB%3Du--txmdFbsQmyMmWKPzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
