Yum Related Versioning Issue

[Richie Rees]

Hi All, 

Come to borrow some of your collective wisdom again,  Seeing a problem installing an rpm using a fairly basic class on a RHEL 5 box using yum as the provider, I am seeing the following error message :-

Error: Could not update: Failed to update to version 5.35.0-3_el5 , got version 5.35.0-3_el5 instead

This is reported as a fail so all the resources that are dependent on the package installing including the service and config files are not set as the class states they should be. 

[Matthew Burgess]

On 19 November 2013 09:48, Richie Rees <richard...@gmail.com> wrote:

Hi All, 

Come to borrow some of your collective wisdom again,  Seeing a problem installing an rpm using a fairly basic class on a RHEL 5 box using yum as the provider, I am seeing the following error message :-

Error: Could not update: Failed to update to version 5.35.0-3_el5 , got version 5.35.0-3_el5 instead

​Warning: Fuzzy memory alert :)  I think I remember seeing this when I was on an x86_64 box which had both a 32-bit and 64-bit version of an RPM installed.  Running 'yum update <package>' on the command line may give you a better indication of what is going on here.

​Regards,

Matt.​

[Dan White]

Details, please.

What is the package in question ?

Are you running 32 bit or 64 bit ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

---

From: "Richie Rees" <richard...@gmail.com>
To: puppet...@googlegroups.com
Sent: Tuesday, November 19, 2013 4:48:48 AM
Subject: [Puppet Users] Yum Related Versioning Issue

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4e79b8ce-ee3d-4b01-a28c-32ce3e401838%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Richie Rees]

Hello again Ygor,

Its a 64 bit internal  package, its only built for the 64 bit platform. there are a number of different versions in the repo but none of the same major build so can't see why it would be getting confused. 

Thanks,

Richie.

[Dan White]

Did you try

yum update --verbose <package>

as suggested ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

---

From: "Richie Rees" <richard...@gmail.com>
To: puppet...@googlegroups.com

Sent: Tuesday, November 19, 2013 8:33:35 AM
Subject: Re: [Puppet Users] Yum Related Versioning Issue

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/11708b3a-6ad4-40b5-afa6-ca3d52c844e5%40googlegroups.com.

[Michael Stahnke]

Sometimes yum (and things calling it) do better when using
package-name.arch like openldap-libs.i386 vs openldap-libs.x86_64 if
that makes sense. I think that's what's happening.

> https://groups.google.com/d/msgid/puppet-users/545694092.4619408.1384868583959.JavaMail.root%40sz0126a.westchester.pa.mail.comcast.net.

[Jason Antman]

I'll wager that Michael is correct here (based on what he says, not just
his knowledge of packaging).

Can you provide the actual, full names of the package in question, or
the rpm -qi output?

My guess, based on having the same problem, is that if
ensure => '5.35.0-3_el5'
is failing, then you'll have success with
ensure => '5.35.0-3_el5.x86_64'

I can't find the supporting documentation at the moment, but based on
how the package is built (well, the values of certain fields/parameters
in the spec file), there are only certain substrings of the full package
name (packagename-X.Y.Z-release.dist.arch) that yum recognizes.

My memory of this is that you can either specify the version (X.Y.Z) or
you have to specify *everything* in the package
name/version/release/dist/arch. Or you can specify "name.arch" and a
version, as Michael suggested.

-jantman

On 11/19/2013 05:09 PM, Michael Stahnke wrote:
> Sometimes yum (and things calling it) do better when using
> package-name.arch like openldap-libs.i386 vs openldap-libs.x86_64 if
> that makes sense. I think that's what's happening.
>
> On Tue, Nov 19, 2013 at 5:43 AM, Dan White <yg...@comcast.net> wrote:
>> Did you try
>>
>> yum update --verbose <package>
>>
>> as suggested ?
>>
>>

>> �Sometimes I think the surest sign that intelligent life exists elsewhere in
>> the universe is that none of it has tried to contact us.�

>> Bill Waterson (Calvin & Hobbes)
>>
>> ________________________________
>> From: "Richie Rees" <richard...@gmail.com>
>> To: puppet...@googlegroups.com
>> Sent: Tuesday, November 19, 2013 8:33:35 AM
>> Subject: Re: [Puppet Users] Yum Related Versioning Issue
>>
>>
>> Hello again Ygor,
>>
>> Its a 64 bit internal package, its only built for the 64 bit platform.
>> there are a number of different versions in the repo but none of the same
>> major build so can't see why it would be getting confused.
>>
>> Thanks,
>>
>> Richie.
>>
>>
>>
>> On Tuesday, 19 November 2013 13:23:47 UTC, Ygor wrote:
>>> Details, please.
>>>
>>> What is the package in question ?
>>>
>>> Are you running 32 bit or 64 bit ?
>>>

>>> �Sometimes I think the surest sign that intelligent life exists elsewhere
>>> in the universe is that none of it has tried to contact us.�

[jcbollinger]

On Wednesday, November 20, 2013 6:22:35 AM UTC-6, Jason Antman wrote:

I'll wager that Michael is correct here (based on what he says, not just
his knowledge of packaging).

Can you provide the actual, full names of the package in question, or
the rpm -qi output?

My guess, based on having the same problem, is that if
ensure => '5.35.0-3_el5'
is failing, then you'll have success with
ensure => '5.35.0-3_el5.x86_64'

This does resemble a package architecture issue, but after analyzing the provider source, I don't think that's it.  The relevant line appears to be this one:

raise Puppet::Error, "Failed to update to version #{should}, got version #{is[:ensure]} instead" if should && should != is[:ensure]

Note in particular that that error will be raised only if 'should' is unequal to 'is[:ensure]', but the error message Richie reports does not appear to show the two differing.  My best guess as as to how to resolve the apparent discrepancy is that the two strings are rendered unequal by an encoding mismatch.  (Thanks a lot, Ruby, for per-string encodings. :-( )  Alternatively, it might be that the 'should' string contains a non-printing character.

I would check the relevant manifest file for non-printing characters first, as that should be relatively easy to do.  I am uncertain how an encoding mismatch might crop up here, or how best to resolve it if it did, but my first attempt would be to ensure that all manifests are encoded in the text encoding for the locale in which the master runs (probably the system's default locale, but verify).


By the way, if you want to specify package arch in a resource declaration, then you must append the .<arch> to the resource title, not add it to the 'ensure' value.

 

I can't find the supporting documentation at the moment, but based on
how the package is built (well, the values of certain fields/parameters
in the spec file), there are only certain substrings of the full package
name (packagename-X.Y.Z-release.dist.arch) that yum recognizes.

My memory of this is that you can either specify the version (X.Y.Z) or
you have to specify *everything* in the package
name/version/release/dist/arch. Or you can specify "name.arch" and a
version, as Michael suggested.

Yum understands name and name-version-release, with or without .arch.  It does not understand name-version (without -release), with or without the arch.


John