Hi List,
I''m trying to specify a 32-bit version of a package that I need
installed alongside the 64-bit version. Looking at this:
http://reductivelabs.com/trac/puppet/ticket/265#comment:9
the problem appears to have been fixed, and this was before the current
0.24.4 release, so I''m assuming that the fix made its way in. However
my configuration (snippet):
package { "mesa-libGLU": ensure => installed }
package { "mesa-libGLU.i386": ensure => installed }
is triggering this on the client machine (when running puppetd --test
--debug):
debug: Puppet::Type::Package::ProviderYum: Not suitable: false value
debug: Puppet::Type::Package::ProviderYum: Executing ''/bin/rpm -q
mesa-libGLU.i386 --nosignature --nodigest --qf %{NAME}
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
Which isn''t installing the 32-bit version. I''ve tried only
including
the i386 line, and I''ve tried specifying x86_64 on the line above to
avoid confusion - all to no avail.
What am I doing wrong?
-Chad
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
On Thu, Jul 17, 2008 at 6:38 PM, Chad Feller <cfeller@gmail.com> wrote:> Hi List, > > I''m trying to specify a 32-bit version of a package that I need > installed alongside the 64-bit version. Looking at this: > > http://reductivelabs.com/trac/puppet/ticket/265#comment:9 > > > the problem appears to have been fixed, and this was before the current > 0.24.4 release, so I''m assuming that the fix made its way in. However > my configuration (snippet): > > package { "mesa-libGLU": ensure => installed } > > package { "mesa-libGLU.i386": ensure => installed } > > is triggering this on the client machine (when running puppetd --test > --debug): > > debug: Puppet::Type::Package::ProviderYum: Not suitable: false value > > debug: Puppet::Type::Package::ProviderYum: Executing ''/bin/rpm -q > mesa-libGLU.i386 --nosignature --nodigest --qf %{NAME} > %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH} > > Which isn''t installing the 32-bit version. I''ve tried only including > > the i386 line, and I''ve tried specifying x86_64 on the line above to > avoid confusion - all to no avail. > > What am I doing wrong? >Stupid question, but do you have the 32-bit repos enabled? Fair warninig, herre just enabling the 32bit repos can cuase allkinds of weridness on 32bit systems when it comes to installing/upgrading packages that have both 32 and 64 bit versions. Evan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jul 17, 4:55 pm, "Evan Hisey" <ehi...@gmail.com> wrote:> On Thu, Jul 17, 2008 at 6:38 PM, Chad Feller <cfel...@gmail.com> wrote: > > Hi List, > > > I''m trying to specify a 32-bit version of a package that I need > > installed alongside the 64-bit version. Looking at this: > > > http://reductivelabs.com/trac/puppet/ticket/265#comment:9 > > > the problem appears to have been fixed, and this was before the current > > 0.24.4 release, so I''m assuming that the fix made its way in. However > > my configuration (snippet): > > > package { "mesa-libGLU": ensure => installed } > > > package { "mesa-libGLU.i386": ensure => installed } > > > is triggering this on the client machine (when running puppetd --test > > --debug): > > > debug: Puppet::Type::Package::ProviderYum: Not suitable: false value > > > debug: Puppet::Type::Package::ProviderYum: Executing ''/bin/rpm -q > > mesa-libGLU.i386 --nosignature --nodigest --qf %{NAME} > > %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH} > > > Which isn''t installing the 32-bit version. I''ve tried only including > > > the i386 line, and I''ve tried specifying x86_64 on the line above to > > avoid confusion - all to no avail. > > > What am I doing wrong? > > Stupid question, but do you have the 32-bit repos enabled? Fair > warninig, herre just enabling the 32bit repos can cuase allkinds of > weridness on 32bit systems when it comes to installing/upgrading > packages that have both 32 and 64 bit versions. > > EvanYou don''t have to specifically enable them (in this instance), as CentOS 5 has both 32-bit and 64-bit packages built by default. For instance 64 and 32 bit versions of Firefox are installed by default on {RHEL,CentOS}5 systems. In the instance that there isn''t a 32-bit package that I need, say mesa-libGLU, I can just type "yum install mesa-libGLU.i386", which I did on another system managed in this configuration that was having the same problem and it worked fine. I just cannot get puppet to install it. -Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi,
I also have the same problem, as a workaround I''ve created the
following
code:
redhat::i386-package{ [ libgcc, zlib, xorg-x11-libs]:}
define redhat::i386-package() {
case $architecture {
x86_64: {
case $operatingsystem {
RedHat: {
exec {"Install $name.i386":
command => "/usr/bin/yum -e0 -d0 -y install
$name.i386",
unless => "/bin/rpm -q --qf ''%{ARCH}''
$name | egrep -q i386"
}
}
}
}
}
}
But the best way to handle this would be in puppet provider.
Ohad
On Fri, Jul 18, 2008 at 8:05 AM, Chad <cfeller@gmail.com> wrote:
>
>
>
> On Jul 17, 4:55 pm, "Evan Hisey" <ehi...@gmail.com> wrote:
> > On Thu, Jul 17, 2008 at 6:38 PM, Chad Feller <cfel...@gmail.com>
wrote:
> > > Hi List,
> >
> > > I''m trying to specify a 32-bit version of a package that
I need
> > > installed alongside the 64-bit version. Looking at this:
> >
> > > http://reductivelabs.com/trac/puppet/ticket/265#comment:9
> >
> > > the problem appears to have been fixed, and this was before the
current
> > > 0.24.4 release, so I''m assuming that the fix made its
way in. However
> > > my configuration (snippet):
> >
> > > package { "mesa-libGLU": ensure => installed }
> >
> > > package { "mesa-libGLU.i386": ensure =>
installed }
> >
> > > is triggering this on the client machine (when running puppetd
--test
> > > --debug):
> >
> > > debug: Puppet::Type::Package::ProviderYum: Not suitable: false
value
> >
> > > debug: Puppet::Type::Package::ProviderYum: Executing
''/bin/rpm -q
> > > mesa-libGLU.i386 --nosignature --nodigest --qf %{NAME}
> > > %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
> >
> > > Which isn''t installing the 32-bit version.
I''ve tried only including
> >
> > > the i386 line, and I''ve tried specifying x86_64 on the
line above to
> > > avoid confusion - all to no avail.
> >
> > > What am I doing wrong?
> >
> > Stupid question, but do you have the 32-bit repos enabled? Fair
> > warninig, herre just enabling the 32bit repos can cuase allkinds of
> > weridness on 32bit systems when it comes to installing/upgrading
> > packages that have both 32 and 64 bit versions.
> >
> > Evan
>
> You don''t have to specifically enable them (in this instance), as
> CentOS 5 has both 32-bit and 64-bit packages built by default. For
> instance 64 and 32 bit versions of Firefox are installed by default on
> {RHEL,CentOS}5 systems. In the instance that there isn''t a 32-bit
> package that I need, say mesa-libGLU, I can just type "yum install
> mesa-libGLU.i386", which I did on another system managed in this
> configuration that was having the same problem and it worked fine. I
> just cannot get puppet to install it.
>
> -Chad
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Hi> I also have the same problem, as a workaround I''ve created the following > code: > > redhat::i386-package{ [ libgcc, zlib, xorg-x11-libs]:} > > define redhat::i386-package() { > case $architecture { > x86_64: { > case $operatingsystem { > RedHat: { > exec {"Install $name.i386": > command => "/usr/bin/yum -e0 -d0 -y install $name.i386", > unless => "/bin/rpm -q --qf ''%{ARCH}'' $name | egrep -q i386" > } > } > } > } > } > } > > But the best way to handle this would be in puppet provider.ever figured out, why the puppet provider fails? I think this should be definitely fixed in the provider, so not everybody have to think about their own defines or providers. (aka interface case) greets pete --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2008/7/18 Peter Meier <peter.meier@immerda.ch>:> ever figured out, why the puppet provider fails? I think this should be > definitely fixed in the provider, so not everybody have to think about > their own defines or providers. (aka interface case)When I was investigating this (I had to force x86_64 on some packages, since yum picked both), I found that it comes down to the package naming convention and how puppet calls yum (and what yum allows for package specifiers). class postgresql83::server inherits postgresql83 { $base = ''servers'' package { "postgresql-server-8.3.3-1PGDG.rhel5.$architecture": alias => "postgresql-server", require => YumRepo["PostgreSQL-mirror"]; ..} is what I ended up with. It''s not pretty, but it works. If the 64 bit package needs the 32 bit one, yum hauls it in automatically for me. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jul 18, 2:49 am, "Duncan Hill" <bajand...@googlemail.com> wrote:> 2008/7/18 Peter Meier <peter.me...@immerda.ch>: > > > ever figured out, why the puppet provider fails? I think this should be > > definitely fixed in the provider, so not everybody have to think about > > their own defines or providers. (aka interface case) > > When I was investigating this (I had to force x86_64 on some packages, > since yum picked both), I found that it comes down to the package > naming convention and how puppet calls yum (and what yum allows for > package specifiers). > > class postgresql83::server inherits postgresql83 { > $base = ''servers'' > package { > "postgresql-server-8.3.3-1PGDG.rhel5.$architecture": > alias => "postgresql-server", > require => YumRepo["PostgreSQL-mirror"]; > ..} > > is what I ended up with. It''s not pretty, but it works. If the 64 > bit package needs the 32 bit one, yum hauls it in automatically for > me.Interesting... so it sounds like I''m not alone on this, and that the provider still isn''t fixed. Going back and reading the ticket (http:// reductivelabs.com/trac/puppet/ticket/265#comment:8), although this was fixed in October (comment #9), it looks like the fix won''t make it in until elmo (0.25.0)? -Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---