You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue happens with smart 1.4.1 and patch for #1086888 applied
Issue happens by calling "smart upgrade"
We encountered the issue while upgrading packages from multiple channels where some packages where multiple times within channels but with different versions. In that case transaction was calculated and after confirmation of changes smart interrupted because a package was missing, but that package was included within channels.
When we removed the packages which were not unique upgrade did work correctly.
After debugging and finding and fixing a quite obvious bug this also did not happen anymore.
After understanding what the patched code actually should do and did before, I would say the issue happens whenever the changeset contains a package to be installed, which was not present on the system before and moreover had no installed package which would be obsoleted by it, and then only, when the channel holds multiple versions of this package.
The bug is in transaction.py in method _upgrade()
Here is the code in question:
for pkg in changeset.keys():
op = changeset.get(pkg)
if (op and op != origchangeset.get(pkg) and
pkg not in locked and pkg not in lockedstates):
try:
cs = changeset.copy()
lk = locked.copy()
if op is REMOVE:
self._install(pkg, cs, lk, None, depth)
elif op is INSTALL:
self._remove(pkg, cs, lk, None, depth)
except Failed, e:
pass
else:
csweight = getweight(cs)
if csweight < weight:
weight = csweight
changeset.setState(cs)
I see no chance that origchangeset ever could not be empty. So I do not really understand the purpose of this code.
Probably this could be removed completely.
The bug here is that when origchangeset is always empty, the operation compared with "op" is always "None", so _remove()/_install() will always happen here unless the package is not locked or statelocked. A package is only statelocked when it was installed in the system before the upgrade procedure took place and upgraded only due to _install() here in the _upgrade() procedure, or when it has been required by another package and it is obvious that there might not be another possibility but to install this package. The lock is not set when there are multiple versions of the same package in the channels.
In our case because of this it removed a package from transaction set, which caused that the transaction set then was not complete anymore and the upgrade failed.
Our setup:
channel configuration:
root@upgrade_3:~/local # smart channel --show
smart channel --disable [r8-2]
type = rpm-md
baseurl = http://192.168.58.129/repo/qa/2.5/r8/2
[rpm-sys]
type = rpm-sys
name = RPM System
[custom-r8-3]
type = rpm-md
baseurl = http://192.168.58.129/repo/qa/2.5/r8/3
[r6-4]
type = rpm-md
baseurl = http://192.168.58.129/repo/qa/2.5/r6/4
[2.5-base]
type = rpm-md
name = 2.5 base
baseurl = http://repository/packages/utm-2.5/base
Original issue on launchpad: Upgrade fails if a required package need to be installed but has multiple versions of it in channels
Issue happens with smart 1.4.1 and patch for #1086888 applied
Issue happens by calling "smart upgrade"
We encountered the issue while upgrading packages from multiple channels where some packages where multiple times within channels but with different versions. In that case transaction was calculated and after confirmation of changes smart interrupted because a package was missing, but that package was included within channels.
When we removed the packages which were not unique upgrade did work correctly.
After debugging and finding and fixing a quite obvious bug this also did not happen anymore.
After understanding what the patched code actually should do and did before, I would say the issue happens whenever the changeset contains a package to be installed, which was not present on the system before and moreover had no installed package which would be obsoleted by it, and then only, when the channel holds multiple versions of this package.
The bug is in transaction.py in method _upgrade()
Here is the code in question:
I see no chance that origchangeset ever could not be empty. So I do not really understand the purpose of this code.
Probably this could be removed completely.
The bug here is that when origchangeset is always empty, the operation compared with "op" is always "None", so _remove()/_install() will always happen here unless the package is not locked or statelocked. A package is only statelocked when it was installed in the system before the upgrade procedure took place and upgraded only due to _install() here in the _upgrade() procedure, or when it has been required by another package and it is obvious that there might not be another possibility but to install this package. The lock is not set when there are multiple versions of the same package in the channels.
In our case because of this it removed a package from transaction set, which caused that the transaction set then was not complete anymore and the upgrade failed.
Our setup:
channel configuration:
does fail:
content of the channels is:
r6-4:
r8-2:
r8-3:
After the fix:
which then installs, because jobsengine is part of the transaction
The text was updated successfully, but these errors were encountered: