Bug 541508

Public Summary:

Problem:

When synching package profiles between two x86_64 systems, where the source
profile has multi-arch packages installed, synching fails with the error:

Failed: Some of the packages requested are not available.',
{'missing_packages': [['SDL', '1.2.7', '8', '', 'i386'], ['alchemist',
'1.0.34', '1', '', 'i386'], ['alsa-lib', '1.0.6', '5.RHEL4', '', 'i386'],
['arts', '1.3.1', '2', '8', 'i386'], ['aspell', '0.50.5', '4.EL4', '12',
'i386'], ['audiofile', '0.2.6', '1.el4.1', '1', 'i386'], ['esound', '0.2.35',
'2', '1', 'i386'], ['evolution-data-server', '1.0.2', '14.el4', '', 'i386'],
['glibc-devel', '2.3.4', '2.43', '', 'i386'], ['libgnome', '2.8.0', '2', '',
'i386'], ['libstdc++-devel', '3.4.6', '11', '', 'i386'], ['openssl-devel',
'0.9.7a', '43.17.el4_7.2', '', 'i386'], ['pam-devel', '0.77', '66.26', '',
'i386'], ['sysfsutils', '1.2.0', '1', '', 'i386']], 'version': 0, 'name':
'packages.runTransaction.packages_not_available'})

It seems to fail to find all the i386 versions of packages for which it is
trying to install both i386 and x86_64 packages.

It does the same evening if you select just one package (but both
architectures), so for example with alchemist only selected:

D: handle_action actionid = 11874, version = 2
D: do_call packages.runTransaction ({'packages': [[['alchemist', '1.0.34', '1',
'', 'x86_64'], 'i'], [['alchemist', '1.0.34', '1', '', 'i386'], 'i']]},)
D: availablePackageList::channels: <up2date_client.rhnChannel.rhnChannelList
instance at 0x2a9af28830>
D: listAllPackages Fetched via: diskcache
D: listAllPackages Fetched via: diskcache
D: listAllPackages Fetched via: diskcache
D: listAllPackages Fetched via: diskcache
D: Sending back response (41, 'Failed: Some of the packages requested are not
available.', {'missing_packages': [['alchemist', '1.0.34', '1', '', 'i386']],
'version': 0, 'name': 'packages.runTransaction.packages_not_available'})

Selecting only the x86_64 version works as expected, it is installed.

Selecting only the i386 package to sync still fails, but if you schedule an
installation of the i386 version of the same package outside of the profile
synch page, installation works!

Steps to reproduce:

1. Install 2 RHEL 4.7 x86_64 systems
2. Register them to RHN Satellite server.
3. Update one of them to RHEL 4.8
4. Schedule a 'Package Profile Sync' on RHEL 4.7 system comparing with the RHEL 4.8 system.
5. Make sure the comparison shows atleast one package with both the archs for e.g alchmeist.i386 and alchemist.x86_64
6. Run rhn_check from the RHEL4.7 system.

>   Desired behavior:
All the packages that are selected to sync are installed if they are in the
relevant channel (which they are).

Additional Info:

The bug is in the following code snippet:

/usr/share/rhn/up2date_client/rhnPackageInfo.py:

def getAllAvailablePackageList(msgCallback=None, progressCallback=None):

for pkg in package_list:
       archScore = rpm.archscore(pkg[4])
       if archScore <= 0:
           # incompatible architecture
           continue
       # pkg might be in multiple channels
       nvre_list = pkg[0:3]
       nvre_list.append(pkg[6])
       nvre = tuple(nvre_list)
       # first package that matches, no need to test anything else
       if not pkgDict.has_key(nvre):
           pkgDict[nvre] = pkg
           continue


When the list of All available package is generated we traverse through
the list to check if there are incompatible archs or also look for
packages that might be available in other channels. Once this is done we
generate a dictionary like {'key' : 'value'}. The key is nothing but
first 3 and 6th value from the package list which looks like:

['alchemist', '1.0.34', '1', '', 'x86_64']

If the list has following value:

['alchemist', '1.0.34', '1', '', 'x86_64', '111462',
'rhel-x86_64-as-4']

These keys are formed for every package in the list. In a multilib package
wherein the differentiating entry is 'arch' we simply do not consider
that as the 'arch' appears at the 5th position. So, once the key is
formed for i386 package we add it and next time we check if the key
already exists if it exists we dont add that package as available. This
was exactly the case for multi-lib packages. So, I modified that list to
form a key which also takes 'arch' into consideration so that for i386
and x86_64 we will have different keys.

Created attachment 373926 [details]
proposed patch

the keys of pkg are:
 name, version, release, epoch, arch, package_size and chanel label
the package_size is not interested in this case. So correct fix should be indeed:
 nvre_list = pkg[:5]
which tooks first 5 items.

But even if I fix this patch, then it works only in few cases. Thats becouse Satellite webUI compare those multilib packages incorrectly. I will file new BZ for that.

commited as rev. 191942

Built up2date-4.9.1-4.el4

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
During the synchronization of package profiles across various systems, a list of all available packages is generated and then checked for incompatible architectures. However, when the source profile included packages that are available for multiple architectures, the synchronization process could fail with the following error:

  Failed: Some of the packages requested are not available.

This update fixes the handling of multi-architecture packages, and the package synchronization now works as expected.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0240.html