How to install 32 bits package on a 64 bits SuSE System

[Nicolas Perron]

Hello,

I would like to install 32 bits packages on a 64 bits SuSE machine ( SLES 11 SP3) with CFEngine but it seems that this is not se easy to do.

As you may know, on SuSE, the package manager is Zypper and its way to install 32 bits packages require to add ".i586" (for example) after the name of the package. Here is an example with the package 'tree':

node1:~/test_cfe3 # cat /etc/SuSE-release 
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

node1:~/test_cfe3 # zypper in tree
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  tree 

The following package is not supported by its vendor:
  tree 

1 new package to install.
Overall download size: 31.0 KiB. After the operation, additional 64.0 KiB will be used.
Continue? [y/n/?] (y): y
Retrieving package tree-1.5.1-2.10.2.1.x86_64 (1/1), 31.0 KiB (64.0 KiB unpacked)
Installing: tree-1.5.1-2.10.2.1 [done]

node1:~/test_cfe3 # rpm -qa --queryformat "i | repos | %{name} | %{version}-%{release} | %{arch}\n" | grep tree
i | repos | tree | 1.5.1-2.10.2.1 | x86_64

node1:~/test_cfe3 # zypper in tree.i586
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to change architecture:
  tree  x86_64 -> i586


The following package is not supported by its vendor:
  tree 

1 package will change arch.
Overall download size: 30.0 KiB. After the operation, 1.0 KiB will be freed.
Continue? [y/n/?] (y): y
Retrieving package tree-1.5.1-2.10.2.1.i586 (1/1), 30.0 KiB (63.0 KiB unpacked)
Installing: tree-1.5.1-2.10.2.1 [done]

node1:~/test_cfe3 # rpm -qa --queryformat "i | repos | %{name} | %{version}-%{release} | %{arch}\n" | grep tree
i | repos | tree | 1.5.1-2.10.2.1 | i586

With CFEngine, if I try to install tree with 'tree.i586', it will not be convergent:

Code extract:

bundle agent test
{

packages:

  "tree.i586"
     package_policy => "add",
     package_method => zypper;
}

Verbose execution:

[...]
cf3> Package (gnuplot,4.2.3-5.34,x86_64) found
cf3> Package (tree,1.5.1-2.10.2.1,i586) found
cf3> Package (gpg-pubkey,307e3d54-4be01a65,(none)) found
[...]
cf3>   Done checking packages and patches
cf3>  ???????????????????????????????????????????????????????????????
cf3> Package version was not specified
cf3> Looking for (tree.i586,*,*)
cf3> No installed packages matched (tree.i586,*,*)
cf3> Looking for (tree.i586,*,*)
cf3> No installed packages matched (tree.i586,*,*)
cf3> Checking if package (tree.i586,*,*) is at the desired state (installed=0,matched=0)
cf3> Package promises to refer to itself as 'tree.i586' to the manager
cf3> Package version seems to match criteria
cf3> Schedule package for addition
cf3> Looking for a package manager called '/usr/bin/zypper --non-interactive install'
cf3> Package (tree.i586,any,any) found
[...]
cf3> Execute scheduled package addition
Installing tree.i586...
cf3> Command prefix '/usr/bin/zypper --non-interactive install '
cf3> Running /usr/bin/zypper --non-interactive install tree.i586  in shell
cf3> Executing /usr/bin/zypper --non-interactive install tree.i586 ...
Q:zypper --non-interac ...:Loading repository data...
Q:zypper --non-interac ...:Reading installed packages...
Q:zypper --non-interac ...:'tree.i586' is already installed.
Q:zypper --non-interac ...:Resolving package dependencies...
Q:zypper --non-interac ...:
Q:zypper --non-interac ...:Nothing to do.
[...]

As for the use of 'tree' with the attribute 'package_architectures => { "i586" };':

Code extract:

bundle agent test
{

packages:

  "tree"
     package_policy => "add",
     package_method => zypper,
     package_architectures => { "i586" };
}

Verbose execution:

[...]
cf3> Package (libmspack0,0.0.20060920alpha-66.8,x86_64) found
cf3> Package (tree,1.5.1-2.10.2.1,x86_64) found
cf3> Package (gpg-pubkey,b37b98a9-4be01a1a,(none)) found
[...]
cf3>  ???????????????????????????????????????????????????????????????
cf3>   Done checking packages and patches
cf3>  ???????????????????????????????????????????????????????????????
cf3> Package version was not specified
cf3>  ... trying listed arch 'i586'
cf3> Looking for (tree,*,i586)
cf3> Matched name 'tree'
cf3> No installed packages matched (tree,*,i586)
cf3> Looking for (tree,*,i586)
cf3> Matched name 'tree'
cf3> No installed packages matched (tree,*,i586)
cf3> Checking if package (tree,*,i586) is at the desired state (installed=0,matched=0)
cf3> Package promises to refer to itself as 'tree' to the manager
cf3> Package version seems to match criteria
cf3> Schedule package for addition
cf3> Looking for a package manager called '/usr/bin/zypper --non-interactive install'
cf3> Package (tree,any,any) found
[...]
cf3> Execute scheduled package addition
Installing tree...
cf3> Command prefix '/usr/bin/zypper --non-interactive install '
cf3> Running /usr/bin/zypper --non-interactive install tree  in shell
cf3> Executing /usr/bin/zypper --non-interactive install tree ...
Q:zypper --non-interac ...:Loading repository data...
Q:zypper --non-interac ...:Reading installed packages...
Q:zypper --non-interac ...:'tree' is already installed.
Q:zypper --non-interac ...:No update candidate for 'tree-1.5.1-2.10.2.1.x86_64'. The highest available version is already installed.
Q:zypper --non-interac ...:Resolving package dependencies...
Q:zypper --non-interac ...:
Q:zypper --non-interac ...:Nothing to do.
[...]

Is there a way to indicate CFEngine to install 32 bits packages with a specific name in the command of zypper ? or is there another way to do the job ?

Thank you

-- 
Nicolas PERRON

[Neil Watson]

https://cfengine.com/docs/3.5/reference-promise-types-packages.html#package_architectures

--
Neil H Watson
Compliance reporting with CFEngine Community http://evolvethinking.com/products/delta-reporting/
Simplify CFEngine with EFL http://evolvethinking.com/evolve-thinkings-free-cfengine-library/
VIM and Cfengine https://github.com/neilhwatson/vim_cf3
CFEngine support and training from Evovle Thinking, http://evolvethinking.com

[Nicolas Perron]

> https://cfengine.com/docs/3.5/reference-promise-types-packages.html#package_architectures
>
>
This is kind to you to guide me through the documentation but if you
re-read my post, you will see that I was using 'package_architectures'
attribute :)
Or is there another thing I must understand ?

--
==========================================
Nicolas PERRON
------------------------------------------
Normation
87 rue de Turbigo, 75003 Paris, France
------------------------------------------
Telephone: +33 (0)1 83 62 56 79
Mobile: +33 (0)6 24 79 31 79
------------------------------------------
Web: http://www.normation.com/
==========================================

[Neil Watson]

On Fri, May 09, 2014 at 04:09:06PM +0200, Nicolas Perron wrote:
>> https://cfengine.com/docs/3.5/reference-promise-types-packages.html#package_architectures
>>
>>
>This is kind to you to guide me through the documentation but if you
>re-read my post, you will see that I was using 'package_architectures'
>attribute :)

Sorry. I think you've done it the same way I would. What version of CF
are you using?

[Nicolas PERRON]

On Fri, 9 May 2014 10:27:03 -0400, Neil Watson wrote:
> On Fri, May 09, 2014 at 04:09:06PM +0200, Nicolas Perron wrote:
>>>
>>> https://cfengine.com/docs/3.5/reference-promise-types-packages.html#package_architectures
>>>
>>>
>>This is kind to you to guide me through the documentation but if you
>>re-read my post, you will see that I was using
>> 'package_architectures'
>>attribute :)
>
> Sorry. I think you've done it the same way I would. What version of
> CF
> are you using?

I was testing this on CFEngine 3.5.2 but I've tested with the same
behavior on CFE 3.5.3 too.

As far as I can understand, 'package_architectures' is a filter to the
list of packages installed to check and the problem here is that the
name of the package is different from the initial one if we need to
specify the architecture.


--

Nicolas PERRON

[Jonathan Clarke]

Did you try using the zypper package_method from the masterfiles for
3.6? I know a lot of work has gone into them, so your bug may just be
fixed in there... If not, I suspect it will gather attention if the
upcoming 3.6 version has a known bug in :)

See
https://github.com/cfengine/masterfiles/blob/master/lib/3.6/packages.cf#L1526.

Jonathan

--
Jonathan Clarke
Normation co-founder and Rudder product strategy
http://www.normation.com - CFEngine training and consulting
http://www.rudder-project.org - Open source automation and compliance in a web UI using CFEngine
http://www.ncf.io - A powerful and structured CFEngine framework

[Klaus Kaempf]

* Nicolas Perron <nicolas...@normation.com> [May 09. 2014 15:26]:

> Hello,
>
> I would like to install 32 bits packages on a 64 bits SuSE machine (
> SLES 11 SP3) with CFEngine but it seems that this is not se easy to do.
>
> As you may know, on SuSE, the package manager is Zypper and its way to
> install 32 bits packages require to add ".i586" (for example) after the
> name of the package.

Although this might work on a SUSE system, better install the
respective -32bit package. The package architecture of such -32bit
packages is still x86_64, but the content is 32bit.

Hth,

Klaus
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

[Ted Zlatanov]

On Sun, 11 May 2014 13:26:57 +0200 Jonathan Clarke <jonatha...@normation.com> wrote:

JC> Did you try using the zypper package_method from the masterfiles for
JC> 3.6? I know a lot of work has gone into them, so your bug may just be
JC> fixed in there... If not, I suspect it will gather attention if the
JC> upcoming 3.6 version has a known bug in :)

JC> See
JC> https://github.com/cfengine/masterfiles/blob/master/lib/3.6/packages.cf#L1526.

I would specifically recommend trying and testing the
`package_specific_latest` bundle:

https://cfengine.com/docs/master/reference-standard-library-packages.html#package_specific_latest

Ted

[phnakarin]

I had a look to "body package_method zypper" here, https://github.com/cfengine/masterfiles/blob/3.6.x/lib/3.5/packages.cf and found that "package_name_convention" had only "$(name)" assigned. That means even you try to assign package_architectures to the promise, CFEngine will not recognise it. Having a promiser like "name.arch" would help to install but it will not be convergent because CFEngine assumes that "name.arch" is "$(name)" and look for "$(name)" as the first field in "/var/cfengine/state/software_packages.csv". If matches, do nothing, otherwise running "package_add_command".

Apart from Ted's suggestion, you may create your own package_method body to support package_architectures like the following;

body package_method my_zypper_arch
{
      package_changes => "bulk";

      package_list_command => "$(paths.path[rpm]) -qa --queryformat \"i | repos | %{name} | %{version}-%{release} | %{arch}\n\"";

      # set it to "0" to avoid caching of list during upgrade
      package_list_update_command => "$(paths.path[zypper]) list-updates";
      package_list_update_ifelapsed => "$(common_knowledge.list_update_ifelapsed)";

      package_patch_list_command => "$(paths.path[zypper]) patches";
      package_installed_regex => "i.*";
      package_list_name_regex    => "$(redhat_knowledge.rpm_name_regex)";
      package_list_version_regex => "$(redhat_knowledge.rpm_version_regex)";
      package_list_arch_regex    => "$(redhat_knowledge.rpm_arch_regex)";

      package_patch_installed_regex => ".*Installed.*|.*Not Applicable.*";
      package_patch_name_regex    => "[^|]+\|\s+([^\s]+).*";
      package_patch_version_regex => "[^|]+\|[^|]+\|\s+([^\s]+).*";

      package_name_convention => "$(name).$(arch)";   ############## adding .$(arch) here ##############

      package_add_command => "$(paths.path[zypper]) --non-interactive install";
      package_delete_command => "$(paths.path[zypper]) --non-interactive remove --force-resolution";
      package_update_command => "$(paths.path[zypper]) --non-interactive update";
      package_patch_command => "$(paths.path[zypper]) --non-interactive patch$"; # $ means no args
      package_verify_command => "$(paths.path[zypper]) --non-interactive verify$";
}

The you have a promise like;

packages:

  "tree"
     package_policy => "add",
     package_method => zypper,
     package_architectures => { "i586" };

Hope this help.

Cheers,
-- Nakarin

[Nicolas Perron]

Hello,

Sorry I forgot to reply before...

You are right: the missing point was that "package_name_convention" has to be set to "$(name).$(arch)" in order to take into account the attribute "package_architectures".

Your answer what exactly what I needed. Thank you :)

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Perron]

> * Nicolas Perron <nicolas...@normation.com> [May 09. 2014 15:26]:
>> Hello,
>>
>> I would like to install 32 bits packages on a 64 bits SuSE machine (
>> SLES 11 SP3) with CFEngine but it seems that this is not se easy to do.
>>
>> As you may know, on SuSE, the package manager is Zypper and its way to
>> install 32 bits packages require to add ".i586" (for example) after the
>> name of the package.
> Although this might work on a SUSE system, better install the
> respective -32bit package. The package architecture of such -32bit
> packages is still x86_64, but the content is 32bit.
>
> Hth,
>
> Klaus

Hi,

I agree with you, the right way is to use SuSE packages with the
"-32bit" suffix but the fact is that all the packages are not covered.
My devs needed some 32 bits packages like "sqlite3-devel" or
"libopenssl-devel" (for example) which are not provided in 32 bits.

Cheers,