32bit and 64bit version of a package

[Alan Laird]

Hi,

I'm trying to write a recipe to install the latest libstdc++ in both
32bit and 64bit flavors and running into issues. Yum only wants to
install the 64bit version if I do:

yum install libstdc++

If I do something like:

package { "libstdc++.i386" : ensure => latest }

It tells me "nothing to do"

Any suggestions on the right way to do this?

Thanks!

Alan

[Nathan Powell]

On Thu, Feb 23, 2012 at 5:57 PM, Alan Laird <al...@laird.net> wrote:
> I'm trying to write a recipe to install the latest libstdc++ in both
> 32bit and 64bit flavors and running into issues.  Yum only wants to
> install the 64bit version if I do:
>
> yum install libstdc++
>
> If I do something like:
>
> package { "libstdc++.i386" : ensure => latest }
>
> It tells me "nothing to do"

What does it "say" if you do:

sudo yum -q install libstdc++.i386

--
Nathan Powell
Linux System Administrator

"Now I see it clearly. My whole life is pointed in one direction. I
see that now. There never has been any choice for me." ~ Travis Bickle

[jcbollinger]

On Feb 23, 4:57 pm, Alan Laird <a...@laird.net> wrote:
> Hi,
>
> I'm trying to write a recipe to install the latest libstdc++ in both
> 32bit and 64bit flavors and running into issues.  Yum only wants to
> install the 64bit version if I do:
>
> yum install libstdc++
>
> If I do something like:
>
> package { "libstdc++.i386" : ensure => latest }
>
> It tells me "nothing to do"

That all sounds like the i386 package is already installed.

> Any suggestions on the right way to do this?

If neither of the things you already tried works, then perhaps you
should fall back to "don't worry about it." If you install software
only from packages, then, since you're usign the yum provider,
installing any other package that needs libstdc++.i386 will cause
libstdc++.i386 to be installed too. And installing only from packages
is an excellent practice, even if it means you sometimes have to roll
your own packages and maintain a local package repository (neither is
hard).

Personally, I am inclined to lean heavily on my package manager. I
think it's more robust and maintainable to have Puppet manage only my
direct package requirements.


John

[Alan Laird]

On Feb 23, 3:39 pm, Nathan Powell <nat...@nathanpowell.org> wrote:

> On Thu, Feb 23, 2012 at 5:57 PM, AlanLaird<a...@laird.net> wrote:
> > I'm trying to write a recipe to install the latest libstdc++ in both
> > 32bit and 64bit flavors and running into issues.  Yum only wants to
> > install the 64bit version if I do:
>
> > yum install libstdc++
>
> > If I do something like:
>
> > package { "libstdc++.i386" : ensure => latest }
>
> > It tells me "nothing to do"
>
> What does it "say" if you do:
>
>   sudo yum -q install libstdc++.i386

Yum tells me "Error: Nothing to do" in that case.

'#yum -y install libstdc++34-3.4.0-1.i386' works without issue.

Alan

[Alan Laird]

This is a third-party package with poorly constructed depends in a
mixed 32 and 64 bit environment as I support moving from Centos5 to
Centos6. Repackaging the vendor package is easy but it would need to
be done at each release.

I've solved the problem of the day by installing the needed libstdc+
+34-3.4.0-1.i386 specifically but it's a clunky way to deal with this
issue.

I would love to find a crafty puppet way to do this.

Alan

[jcbollinger]

On Feb 27, 11:28 am, Alan Laird <a...@laird.net> wrote:
> On Feb 23, 3:39 pm, Nathan Powell <nat...@nathanpowell.org> wrote:
>
>
>
>
>
> > On Thu, Feb 23, 2012 at 5:57 PM, AlanLaird<a...@laird.net> wrote:
> > > I'm trying to write a recipe to install the latest libstdc++ in both
> > > 32bit and 64bit flavors and running into issues.  Yum only wants to
> > > install the 64bit version if I do:
>
> > > yum install libstdc++
>
> > > If I do something like:
>
> > > package { "libstdc++.i386" : ensure => latest }
>
> > > It tells me "nothing to do"
>
> > What does it "say" if you do:
>
> >   sudo yum -q install libstdc++.i386
>
> Yum tells me "Error: Nothing to do" in that case.

And that says that the package is already installed. You could verify
that in a variety of ways, such as "rpm -q libstdc++" or "yum list
installed libstdc++" or even "yum list installed 'libstdc++*'". Why
is "Nothing to do" not an acceptable answer?

> '#yum -y install libstdc++34-3.4.0-1.i386' works without issue.

Part of your problem may be that libstdc++.{i386,x86_64} is not the
same package as libstdc++34.{i386,i686,x86_64}. The latter is
probably a "compatibility library" that provides an _old_ version of
libstdc++ (apparently 3.4.0) on systems whose standard version is
newer (possibly alongside the standard version). I'm guessing based
on naming conventions, however, because there is no such package
distributed from the standard CentOS 5/6 repositories.

If libstdc++34 is the package you really want, then that's what you
should ask Puppet to ensure present. If you ask for a diferent
package, then you should not be surprised when that's the package
Puppet tries to give you.


John

[Elias Abacioglu]

I have a similar problem. I did not find a way to install just the 32bit
package.
I wanted to install 32 bit compat-libstdc++33.i686 because HP Operations
Agent needs it, even if it's a 64 bit agent.

You can do like this: package { 'compat-libstdc++-33.i686' : ensure =>
present }

But the problem is it's a different 32bit architecture for different
distributions and versions.
For RHEL5 and newer it's i686. For older it's i386. SLES11SP1 it's
i586.. etc.
So the code will have to contain a big case or if for different linux
distros and major version setting a variable $x86arch.
And then you need to have a package { "compat-libstdc++-33.${x86arch}" :
ensure => present }

If someone has a better solution, please let me know :)

/Raboo

[Alan Laird]

On Feb 27, 3:57 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
> > > On Thu, Feb 23, 2012 at 5:57 PM, AlanLaird<a...@laird.net> wrote:
> > > > I'm trying to write a recipe to install the latest libstdc++ in both
> > > > 32bit and 64bit flavors and running into issues.  Yum only wants to
> > > > install the 64bit version if I do:
>
> > > > yum install libstdc++
>
> > > > If I do something like:
>
> > > > package { "libstdc++.i386" : ensure => latest }
>
> > > > It tells me "nothing to do"
>

> And that says that the package is already installed.  You could verify
> that in a variety of ways, such as "rpm -q libstdc++" or "yum list
> installed libstdc++" or even "yum list installed 'libstdc++*'".  Why
> is "Nothing to do" not an acceptable answer?

The issue I'm chasing is that I need to install a 32bit libstdc++ to
support a vendor supplied rpm and I already have the 64bit libstdc++
installed. Before today, I was hacking my way around this issue by
installing the 32bit libstdc++ rpm by a package statement that uses
name.version.architecture. This is was working until one of the
systems in my pool had a newer version of the same name and
architecture which causes puppet to throw this error:

err: /Stage[main]/Lsi6::Management/Package[libstdc++34-3.4.0-1.i386]/
ensure: change from absent to present failed: Execution of '/usr/bin/
yum -d 0 -e 0 -y install libstdc++34-3.4.0-1.i386' returned 1:

Transaction Check Error:
file /usr/lib/libstdc++.so.6 from install of libstdc+
+34-3.4.0-1.i386 conflicts with file from package libstdc+
+-4.4.6-3.el6.i686

It seems like there must be an elegant way to install the latest of
name.*.architecture where architecture is i386 or i686.

Alan

[jcbollinger]

On Mar 19, 8:29 pm, Alan Laird <a...@laird.net> wrote:
>
> The issue I'm chasing is that I need to install a 32bit libstdc++ to
> support a vendor supplied rpm and I already have the 64bit libstdc++
> installed.

So the vendor RPM doesn't correctly identify its requirements? That's
quite strange, as the RPM build tools are really quite good at
identifying library dependencies, including architecture. If the
RPM's requires are right and a suitable library is available in one of
the configured repositories, then yum should find it and install it
automatically when you ask it to install the main RPM. That's one of
the main selling points of yum.

In the unlikely event that the vendor RPM really is broken, then
perhaps the best course of action would be to ask the vendor to fix
it. If that isn't possible / fruitful then you could try using
rpmrebuild on the binary RPM to fix the package yourself.

If the RPM is correct, then all this other work you are trying to do
is probably pointless. Just let yum do its job.

>  Before today, I was hacking my way around this issue by
> installing the 32bit libstdc++ rpm by a package statement that uses
> name.version.architecture.  This is was working until one of the
> systems in my pool had a newer version of the same name and
> architecture which causes puppet to throw this error:
>
> err: /Stage[main]/Lsi6::Management/Package[libstdc++34-3.4.0-1.i386]/
> ensure: change from absent to present failed: Execution of '/usr/bin/
> yum -d 0 -e 0 -y install libstdc++34-3.4.0-1.i386' returned 1:
>
> Transaction Check Error:
>   file /usr/lib/libstdc++.so.6 from install of libstdc+
> +34-3.4.0-1.i386 conflicts with file from package libstdc+
> +-4.4.6-3.el6.i686

That's a package incompatibility problem. It really oughtn't to be
the case that any machine is configured with yum repos that contain
both of those packages. Perhaps the problem is that the libstdc++34
package you are trying to install is broken, as I think GCC 3's libstdc
++ ought to be /usr/lib/libstdc++.so.5, not *.6.

Is that 32-bit package coming from your distro's repo, or from some
third-party repo? The second package name it appears you may be using
RHEL 6 or one of its clones, such as CentOS 6, but the 32-bit package
is certainly not from any of those distributions. With RHEL-family
distros, you should be looking at package "compat-libstdc++-33" for
the GCC 3 C++ lib.

> It seems like there must be an elegant way to install the latest of
> name.*.architecture where architecture is i386 or i686.

Sadly, there isn't. RPMs have a composite identifier (name, arch)
that has never meshed well with Puppet's model. That causes few
problems in practice, however, because yum does a decent job of
papering over the distinction, because it only affects multilib
systems, and because it is rare that you need to specify a particular
arch to Puppet even on multilib systems.

In your case, I think you have at least one of these deeper problems:

1) Your Puppet manifests overspecify your requirements. You shouldn't
need to specify an RPM's requirements to Puppet when you are using the
Yum provider. Let yum do its job, and you can get on with your own.

2) Your yum repository configuration is screwed up. It appears to
include repos that are not fully compatible with the distro you are
using. If you cannot altogether remove / disable the offending repos
then at least set up priorities, excludes, includepkgs, or other
options to limit the view of those repositories to the packages you
need from them.


John

[bg]

I may not understand your problem fully, but I do something similar in one of my base classes as I had a similar HP software dependency:

    case $operatingsystem {

        centos: {

            case $operatingsystemrelease {

                5.0,5.1,5.2,5.3,5.4,5.5,5.6,5.7,5.8,5.9: { include rhel5, rhel5-absent }

                6.0,6.1,6.2,6.3,6.4,6.5,6.6,6.7,6.8,6.9: { include rhel6, rhel6-absent }

            }

        }

        redhat: {

            case $operatingsystemrelease {

                5.0,5.1,5.2,5.3,5.4,5.5,5.6,5.7,5.8,5.9: { include rhel5, rhel5-absent }

                6.0,6.1,6.2,6.3,6.4,6.5,6.6,6.7,6.8,6.9: { include rhel6, rhel6-absent }

            }

        }

    }

Then in rhel6.pp

class rhel6 {

     package {

           ["at",

           "compat-libstdc++-296",

           "compat-libstdc++-33",

           "compat-libstdc++-33.i686",]:

           ensure => present,

           provider => yum,}

In rhel5.pp

class rhel5 {

     package {

           ["alchemist",

           "anacron",

           "at",

           "compat-libstdc++-296",

           "compat-libstdc++-33",

           "compat-libstdc++-33.i386",]:

           ensure => present,

           provider => yum,}

My Puppet-foo could use some work, but you can see the logic I employ.

Brian