Bug 193563

*** Bug 197115 has been marked as a duplicate of this bug. ***

If both arches are installed, why not update them both to their latest versions?
I ran into that situation in production, where we needed both 64 and 32 bit pkgs
of the same.

From tickets that I've seen and discussions that I heard our multiarch support
at least on x86 needs further investigation.

the client is basically doing the right thing. Its taking the info given by
server (Transactiondata) and comparing it to the pkgList from
getallavailablepkg. But the problem i see is the server is ignorant of arch info
and sends only nevr and mode( i/e/u) and send arch as always ''. Now due to this
when we compare the pkgs we might be getting a i386 pkg while the client is
looking for a x86_64. Now we compare it to the pkgList and see that we have a
i386 but when it comes to downloading through getPackage it breaks saying it
needs a 64bit dep. So the whole think is a bunch of heuristics. 

The best thing to do is make the server aware of the arch so that client can be
sure that its sent the right pkg, instead of comapring blindly.

a test that i did is a s follows:

this is what the transaction data sends:

1.

({'packages': [[['apr-util', '0.9.4', '21', '', ''], 'i']]},)

as we can see there is no arch..

2. 
getallpakgavailble gives a list of all available in this form.
[['apr-util', '0.9.4', '21', '', 'x86_64', '56643', 'rhel-x86_64-as-4']]

we do have arch info here, but useless in terms that we guess for a best arch in
case 1, which is entirly heuristics.

this results in the following:

[(('apr-util', '0.9.4', '21'), ('libapr-0.so.0()(64bit)', None), 0, None, 0)]
(18, 'Failed: packages requested raised dependency problems', {'failed_deps':
((('apr-util', '0.9.4', '21'), ('libapr-0.so.0()(64bit)', ''), 0, '', 0),),
'version': '0', 'name': 'packages.runTransaction.failed_deps'})

so now we have  the resultant deps.

When doing a profile to profile compare if we see these deps the most possible
case is due to heuristics.

Yea we could do a simple depSolver here, but that might just worsen it. We are
already playing a guessing game uptill here, lets make the server aware of the
arch and be sure that we have a right pkg info to compare for proper
functionality of the client. 

I think that'll simplify most cases. This could be more work than estimated for
the current timeframe, but probably worth it.

ok I have a simple dep solver which basically
- grabs all the deps,
- makes an xmlrpc call to server
- gets all the packages that provides this dep 
- and adds it to the transaction.

but I'm not sure how we want to process deps caused by downgrades/remove:

consider this scenerio:

- client has package a.1.1 which needs to be downgraded to a.1.0.
- the transaction marks a.1.1 as 'e'(remove) and a.1.0 as 'i'(install).
- but there is a package b.1.1 with requires >= a.1.1 
- In this case do we want to remove b.1.1 along with a.1.1?
or do we want to remove the this action from the queue
or do we want to raise an exception with failed deps..

Also in runTransaction, after we run ts.check(), when we get deps, there is no
way for us to say what caused this dep (is it due to 'e' or 'i') without this
info we cannot decide whether to add the package back to transaction as
ts.addInstall() or ts.addErase().

So if we were certain that deps are due to missing pkgs then the problem is
easy, we just make an rpx call get the missing package and complete the
transaction. But the problem is if it conflict as mentioned in above scenerio
then our dep solver is not going to work.

Either case, we might either end up with more packages than needed or end up
loosing few if we solve for downgrades.

The Dep solver should be in a working state now, just want to pound a little
more on it.

here is an example case on when rhn_check throws a dep and how we solve it with
our dep solver:
I'm just pasting the last few phases of solving afetr the deps arise..

DEPS##################### [(('cyrus-sasl', '2.1.19', '5.EL4'), ('libpam.so.0',
None), 0, None, 0), (('libwvstreams', '3.75.0', '2'), ('libpam.so.0', None), 0,
None, 0), (('pam_ccreds', '1', '3'), ('libpam.so.0', None), 0, None, 0),
(('pam_krb5', '2.1.8', '1'), ('libpam.so.0', None), 0, None, 0),
(('cyrus-sasl-plain', '2.1.19', '5.EL4'), ('libpam.so.0', None), 0, None, 0),
(('redhat-lsb', '3.0', '8.EL'), ('libpam.so.0', None), 0, None, 0),
(('nss_ldap', '226', '17'), ('libpam.so.0', None), 0, None, 0), (('libuser',
'0.52.5', '1.el4.1'), ('libpam.so.0', None), 0, None, 0), (('samba-common',
'3.0.10', '1.4E.9'), ('libpam.so.0', None), 0, None, 0), (('pam_ccreds', '1',
'3'), ('libpam_misc.so.0', None), 0, None, 0), (('libuser', '0.52.5',
'1.el4.1'), ('libpam_misc.so.0', None), 0, None, 0)]
%%%%%%%%%%%%%%%SERVER CALL%%%%%%
SSSSSOLVED {'libpam_misc.so.0': [['pam', '0.77', '66.17', '', 'i386'], ['pam',
'0.77', '66.14', '', 'i386'], ['pam', '0.77', '66.13', '', 'i386'], ['pam',
'0.77', '66.11', '', 'i386'], ['pam', '0.77', '66.5', '', 'i386'], ['pam',
'0.77', '65.1', '', 'i386'], ['pam', '0.77', '66.17', '', 'i386'], ['pam',
'0.77', '66.14', '', 'i386'], ['pam', '0.77', '66.13', '', 'i386'], ['pam',
'0.77', '66.11', '', 'i386'], ['pam', '0.77', '66.5', '', 'i386'], ['pam',
'0.77', '65.1', '', 'i386'], ['pam', '0.77', '65.1', '', 'i386'], ['pam',
'0.77', '66.5', '', 'i386'], ['pam', '0.77', '66.11', '', 'i386'], ['pam',
'0.77', '66.13', '', 'i386'], ['pam', '0.77', '66.14', '', 'i386'], ['pam',
'0.77', '66.17', '', 'i386']], 'libpam.so.0': [['pam', '0.77', '66.17', '',
'i386'], ['pam', '0.77', '66.14', '', 'i386'], ['pam', '0.77', '66.13', '',
'i386'], ['pam', '0.77', '66.11', '', 'i386'], ['pam', '0.77', '66.5', '',
'i386'], ['pam', '0.77', '65.1', '', 'i386']]}
AAAAAAAAAllLLLLLLLl PKGGGG INNNNNNNFO ['pam', '0.77', '66.17', '', 'i386',
'1939983', 'rhel-x86_64-as-4']

D: getPackage ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
D: Package ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
Fetched via: diskcache
SKIP as this is outside our boundary ['pam', '0.77', '66.14', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.13', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.11', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.5', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '65.1', '', 'i386']
AAAAAAAAAllLLLLLLLl PKGGGG INNNNNNNFO ['pam', '0.77', '66.17', '', 'i386',
'1939983', 'rhel-x86_64-as-4']
#############pkg not in ADDEDDDD#### ['pam', '0.77', '66.17', '', 'i386']
warning: package pam = 0.77-66.17 was already added, replacing with pam <=
0.77-66.17
D: getPackage ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
D: Package ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
Fetched via: diskcache
SKIP as this is outside our boundary ['pam', '0.77', '66.14', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.13', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.11', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.5', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '65.1', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '65.1', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.5', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.11', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.13', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.14', '', 'i386']
AAAAAAAAAllLLLLLLLl PKGGGG INNNNNNNFO ['pam', '0.77', '66.17', '', 'i386',
'1939983', 'rhel-x86_64-as-4']
#############pkg not in ADDEDDDD#### ['pam', '0.77', '66.17', '', 'i386']
warning: package pam = 0.77-66.17 was already added, replacing with pam <=
0.77-66.17
D: getPackage ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
D: Package ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
Fetched via: diskcache
AAAAAAAAAllLLLLLLLl PKGGGG INNNNNNNFO ['pam', '0.77', '66.17', '', 'i386',
'1939983', 'rhel-x86_64-as-4']
#############pkg not in ADDEDDDD#### ['pam', '0.77', '66.17', '', 'i386']
warning: package pam = 0.77-66.17 was already added, replacing with pam <=
0.77-66.17
D: getPackage ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
D: Package ['pam', '0.77', '66.17', '', 'i386', '1939983', 'rhel-x86_64-as-4']
Fetched via: diskcache
SKIP as this is outside our boundary ['pam', '0.77', '66.14', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.13', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.11', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '66.5', '', 'i386']
SKIP as this is outside our boundary ['pam', '0.77', '65.1', '', 'i386']
DEPS CLEANED
warning: /etc/security/limits.conf created as /etc/security/limits.conf.rpmnew
warning: /etc/pam.d/other created as /etc/pam.d/other.rpmnew
warning: /etc/security/access.conf created as /etc/security/access.conf.rpmnew
warning: /etc/security/chroot.conf created as /etc/security/chroot.conf.rpmnew
warning: /etc/security/console.perms created as /etc/security/console.perms.rpmnew
warning: /etc/security/group.conf created as /etc/security/group.conf.rpmnew
warning: /etc/security/limits.conf created as /etc/security/limits.conf.rpmnew
warning: /etc/security/opasswd created as /etc/security/opasswd.rpmnew
warning: /etc/security/pam_env.conf created as /etc/security/pam_env.conf.rpmnew
warning: /etc/security/time.conf created as /etc/security/time.conf.rpmnew
D: Sending back response (0, 'packages.transaction ran successfully', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})

Before Fix:
-----------

Summary:  	Package Synchronization scheduled by praddb
Details: 	This action will be executed after 2006-12-19 09:47:34 EST.

This action's status is: Failed.
The client picked up this action on 2006-12-19 09:47:48 EST.
The client completed this action on 2006-12-19 09:47:51 EST.
Client execution returned "Failed: packages requested raised dependency
problems" (code 18)
Changes Scheduled:

    * Remove audit-1.0.15-1.EL4
    * Replace pam-0.77-66.11 with pam-0.77-66.17

Dependency errors encountered:

    * cyrus-sasl-2.1.19-5.EL4 requires libpam.so.0
    * cyrus-sasl-plain-2.1.19-5.EL4 requires libpam.so.0
    * libuser-0.52.5-1.el4.1 requires libpam_misc.so.0
    * libuser-0.52.5-1.el4.1 requires libpam.so.0
    * libwvstreams-3.75.0-2 requires libpam.so.0
    * nss_ldap-226-17 requires libpam.so.0
    * pam_ccreds-1-3 requires libpam_misc.so.0
    * pam_ccreds-1-3 requires libpam.so.0
    * pam_krb5-2.1.8-1 requires libpam.so.0
    * redhat-lsb-3.0-8.EL requires libpam.so.0
    * samba-common-3.0.10-1.4E.9 requires libpam.so.0

Time: 	2006-12-19 09:47:44 EST


Afetr Fix:
-------------

Summary:  	Package Synchronization scheduled by praddb
Details: 	This action will be executed after 2006-12-19 10:10:30 EST.

This action's status is: Completed.
The client picked up this action on 2006-12-19 11:02:24 EST.
The client completed this action on 2006-12-19 11:02:54 EST.
Client execution returned "packages.transaction ran successfully" (code 0)
Changes Scheduled:

    * Remove audit-1.0.15-1.EL4
    * Replace pam-0.77-66.11 with pam-0.77-66.17

Time: 	2006-12-19 10:10:40 EST

example for downgrade:
-----------------------

DEPS##################### [(('dbus', '0.22', '12.EL.7'), ('libaudit.so.0',
None), 0, None, 0),
 (('cyrus-sasl', '2.1.19', '5.EL4'), ('libpam.so.0', None), 0, None, 0),
(('libwvstreams', '3.75.0', '2
'), ('libpam.so.0', None), 0, None, 0), (('pam_ccreds', '1', '3'),
('libpam.so.0', None), 0, None, 0), 
(('pam_krb5', '2.1.8', '1'), ('libpam.so.0', None), 0, None, 0),
(('cyrus-sasl-plain', '2.1.19', '5.EL4
'), ('libpam.so.0', None), 0, None, 0), (('redhat-lsb', '3.0', '8.EL'),
('libpam.so.0', None), 0, None,
 0), (('nss_ldap', '226', '17'), ('libpam.so.0', None), 0, None, 0),
(('libuser', '0.52.5', '1.el4.1'),
 ('libpam.so.0', None), 0, None, 0), (('samba-common', '3.0.10', '1.4E.9'),
('libpam.so.0', None), 0, N
one, 0), (('pam_ccreds', '1', '3'), ('libpam_misc.so.0', None), 0, None, 0),
(('libuser', '0.52.5', '1.
el4.1'), ('libpam_misc.so.0', None), 0, None, 0)]
%%%%%%%%%%%%%%%SERVER CALL%%%%%%
SSSSSOLVED {'libaudit.so.0': [['audit-libs', '1.0.15', '1.EL4', '', 'i386'],
['audit-libs', '1.0.14', '
1.EL4', '', 'i386'], ['audit-libs', '1.0.12', '1.EL4', '', 'i386'],
['audit-libs', '1.0.3', '6.EL4', ''
, 'i386']], 'libpam_misc.so.0': [['pam', '0.77', '66.17', '', 'i386'], ['pam',
'0.77', '66.14', '', 'i3
86'], ['pam', '0.77', '66.13', '', 'i386'], ['pam', '0.77', '66.11', '',
'i386'], ['pam', '0.77', '66.5
', '', 'i386'], ['pam', '0.77', '65.1', '', 'i386'], ['pam', '0.77', '66.17',
'', 'i386'], ['pam', '0.7
7', '66.14', '', 'i386'], ['pam', '0.77', '66.13', '', 'i386'], ['pam', '0.77',
'66.11', '', 'i386'], [
'pam', '0.77', '66.5', '', 'i386'], ['pam', '0.77', '65.1', '', 'i386'],
['audit-libs', '1.0.15', '1.EL
4', '', 'i386'], ['audit-libs', '1.0.14', '1.EL4', '', 'i386'], ['audit-libs',
'1.0.12', '1.EL4', '', '
i386'], ['audit-libs', '1.0.3', '6.EL4', '', 'i386'], ['audit-libs', '1.0.15',
'1.EL4', '', 'i386'], ['
audit-libs', '1.0.14', '1.EL4', '', 'i386'], ['audit-libs', '1.0.12', '1.EL4',
'', 'i386'], ['audit-lib
s', '1.0.3', '6.EL4', '', 'i386'], ['audit-libs', '1.0.3', '6.EL4', '', 'i386'],
['audit-libs', '1.0.12
', '1.EL4', '', 'i386'], ['audit-libs', '1.0.14', '1.EL4', '', 'i386'],
['audit-libs', '1.0.15', '1.EL4
', '', 'i386'], ['pam', '0.77', '65.1', '', 'i386'], ['pam', '0.77', '66.5', '',
'i386'], ['pam', '0.77
', '66.11', '', 'i386'], ['pam', '0.77', '66.13', '', 'i386'], ['pam', '0.77',
'66.14', '', 'i386'], ['
pam', '0.77', '66.17', '', 'i386']], 'libpam.so.0': [['pam', '0.77', '66.17',
'', 'i386'], ['pam', '0.7
7', '66.14', '', 'i386'], ['pam', '0.77', '66.13', '', 'i386'], ['pam', '0.77',
'66.11', '', 'i386'], [
'pam', '0.77', '66.5', '', 'i386'], ['pam', '0.77', '65.1', '', 'i386'],
['audit-libs', '1.0.15', '1.EL
4', '', 'i386'], ['audit-libs', '1.0.14', '1.EL4', '', 'i386'], ['audit-libs',
'1.0.12', '1.EL4', '', '
i386'], ['audit-libs', '1.0.3', '6.EL4', '', 'i386'], ['audit-libs', '1.0.3',
'6.EL4', '', 'i386'], ['a
udit-libs', '1.0.12', '1.EL4', '', 'i386'], ['audit-libs', '1.0.14', '1.EL4',
'', 'i386'], ['audit-libs
', '1.0.15', '1.EL4', '', 'i386']]}
D: getPackage ['pam', '0.77', '66.11', '', 'x86_64', '2005715', 'rhel-x86_64-as-4']
D: Package ['pam', '0.77', '66.11', '', 'x86_64', '2005715', 'rhel-x86_64-as-4']
Fetched via: diskcache
DEPS CLEANED
D: Sending back response (0, 'packages.transaction ran successfully', {})
 in rhn_check before actions
run_actions packages.checkNeedUpdate ('rhnsd=1',)
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})

Summary:  	Package Synchronization scheduled by praddb
Details: 	This action will be executed after 2006-12-19 12:10:12 EST.

This action's status is: Completed.
The client picked up this action on 2006-12-19 12:10:26 EST.
The client completed this action on 2006-12-19 12:10:44 EST.
Client execution returned "packages.transaction ran successfully" (code 0)
Changes Scheduled:

    * Replace audit-libs-1.0.15-1.EL4 with audit-libs-1.0.3-6.EL4
    * Replace pam-0.77-66.17 with pam-0.77-66.11
    * Remove pychecker-0.8.14-1.python23

Time: 	2006-12-19 12:10:22 EST

The depSolver seems to work well. One problem i noticed is there seems to be a
bug in webui related to kernels.

rhn_check keep getting this error:

END: solve deps Wed Dec 20 21:05:39 2006
deps solved
New Up2date available
D: Sending back response (40, "Failed: The transaction failed for the following
reasons:\n[('package kernel-2.6.9-34.0.2.EL is already installed', (2, '',
0L))]", {'failed_elements': [('package kernel-2.6.9-34.0.2.EL is already
installed', (2, '', 0L))], 'version': '0', 'name':
'packages.runTransaction.failed_transaction'})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})
[root@test08-64 ~]#

The reason is that the web side of code incorreclty allows the schedule of sync
between kernals even though the kernels are the same on both boxes and the diff
sent to client has only one of it set to install. 

as follows:
the scheduled actions queue sent to client looks like this D: do_call
packages.runTransaction ({'packages': [[['kernel', '2.6.9', '34.0.2.EL', '',
''], 'i']]....]

so only one of those kernel packages is scheduled for install and not for
removal and so it fails with package already installed as above.

I'm opening another bug on this. But far as this bug is concerned, the depSOlver
should pretty much all be set. No server changes for dep solver stuff. But the
webui has to be fixed for kernel upgrades/downgrades to work correctly.

Created attachment 144143 [details]
kernel pkgs shown for sync incorrectly 

As we can see the two boxes ahve the same kernels and it still shows it in the
webui diff

[root@test08-64 ~]# rpm -q --qf='%{n}-%{v}-%{r}-%{ARCH}\n' kernel
kernel-2.6.9-22.EL-x86_64
kernel-2.6.9-34.0.2.EL-x86_64

[root@test07-64 up2date_client]# rpm -q --qf='%{n}-%{v}-%{r}-%{ARCH}\n' kernel
kernel-2.6.9-22.EL-x86_64
kernel-2.6.9-34.0.2.EL-x86_64

this should not happen.

fyi this is the bug for the above issue:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220386

once this is fixed we are good to go.

except for the server side glitches, the client depsolver now should try its
best to solve the deps deu to profile sync. moving to modified

Proposed Test Plan:
-------------------

- grab two x86_64 boxes/or two i386 , one with 4u2 and another with 4u4, and
register to hosted/sat.(these two must be subscribed to same base channel,
including the same arch ofcourse)

- goto server webui systems->details->software->packages->profiles

- create a package profiles for both 4u2 and 4u4.if the base channels match, it
should allow you to compare the two systems now.

- now click compare profiles/stored profiles and should give you a list of
upgrades and downgrades.

- choose all and schedule a profile sync( either a downgrade from 4u4 to 4u2 or
upgrade from 4u2 to 4u4)

- make sure you turn off osad on the client so you can monitor rhn_check..

- go back to client and run rhn_check -vvv and notice that the schedule sync is
now picked up by rhn_check.

- Now rhn_check checks for deps and if it finds any should try to solve the
deps. It should try its best to slove the deps and add the desp back to
transaction set. 
- Sometimes dep solving might fail if its trying to solve outside the package
universe. But this is ok. We need to make sure, rhn_check is trying to solve deps.

- the main thing here is the new dep solver that rhn_check tries to perform.

- now when you go back to the ui, you should see that 4u2 should be upgraded to
4u4 or vice-versa, if the deps got resolved.

- the two systems should look alike, now you could install a bunch of new
packages on one and try to recompare and should see the diff on the ui. follow
the same steps above.

The dep solver is a work around for the server side arch problem.. adding arch
capability on server involves some changes to tables and stuff which we decided
was not appropriate for a u release. Hence we added a dep solver which tries to
solve the multi arch deps (yea we'll end up with more packages that we need at
some point, but thats expected. 

Fixing the sat to include arches is out of scope for 4u5 release and we don't
have an ack or any decision to do it yet.

So the answer to your question is, yes we are addressing this issue from client
perspective by doing a dep solving on rhn_check, so that the profiles are syncable.

Jan & Cliff:

The issue trackers this bug is trying to address (and my fix as well) is  Issue
93392,93368 as mentioned in comment#3 & comment#5 of this bug.

Issue 93392: 
-------------
CRM 880438

Customer is attempting to package sync a RHEL4 GA system to a update 3 system.

The even fails with dependency issues.  

Issue 93368:
------------
CRM #779468 -

Rollback Fails on a 64bit system


The issue you are mentioning could still be an outstanding one. I think the
problem here is, somehow we missed aligning the issue you are addressing to the
right bug.

I would suggest opening a seperate bug to track the issue that you are referring
to that is:
http://seg.rdu.redhat.com/scripts/hotfix/edit.pl?id=1516

yea the IT is not descriptive enough on what conditions this is happening. All i
see is

"It seems that only the package with the default architecture is deployed when
syncronizing to a profile which contains a package in two different architectures."

which is not necessarly what we are addressing in this bugzilla in which the
issue is where once we started syncing how do we dependency solve in case of
raised deps and not error on multilib packages without dep solving.

It would probably be more useful if we request for more info on this issue
tracker on some logs/error messages etc.

This appears to be fixed... it's not possible to fully test this against RHN
hosted due to bug #235124, however the dependency checker does appear to be
functioning alright.

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 the 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-2007-0250.html