smartpm / smart Goto Github PK
View Code? Open in Web Editor NEWSmart Package Manager
Home Page: http://smartpm.github.io/smart/
License: GNU General Public License v2.0
Smart Package Manager
Home Page: http://smartpm.github.io/smart/
License: GNU General Public License v2.0
======================= Smart Package Manager ======================= :Author: Gustavo Niemeyer :Contact: [email protected] :Revision: $Rev$ :Date: $Date$ .. contents:: -------- Overview -------- The **Smart Package Manager** project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc). From `The Free On-line Dictionary of Computing`:: smart 1. <programming> Said of a program that does the {Right Thing} in a wide variety of complicated circumstances. (...) -------------- Project Status -------------- The development of Smart Package Manager started on May 4th, 2004, and version 1.0 was released on Aug 14th, 2008, after extended beta testing. -------- Features -------- Modular ------- Smart has been developed with modularity and flexibility in mind. It's completely backend-based, and package-manager-agnostic. Support is currently implemented for **RPM**, **DPKG**, and **Slackware** package management systems, and porting it to new systems should be very easy. Smart Transactions ------------------ That's one of the most interesting aspects of Smart Package Manager, and the one who has motivated calling it `smart`. Computing transactions respecting the relations involved in the package management world may become an unpleasant task when thousands of packages and relations are being considered, or even when just a few complex relations turn the most obvious choice into the unwanted one. While other applications try to find a possible solution to satisfy the relations involved in some user-requested operation, and sometimes even fail to do so [1]_, Smart goes beyond it. In the kernel of Smart Package Manager lives an algorithm that will not only find a solution, if one is available, but will find the best solution. This is done by quickly weighting every possible solution with a pluggable policy, which redefines the term "best" depending on the operation goal (install, remove, upgrade, etc). This behavior has many interesting consequences. In upgrades, for instance, while precedence is given to newer versions, intermediate versions may get selected if they bring a better global result for the system. Packages may even be reinstalled, if different packages with the same name-version pair have different relations, and the one not installed is considered a better option. Another important goal achieved with the transaction algorithm is that, even though it is able to check and fix relations in the whole system, it will work even when there are broken relations in installed packages. Only relations related to the operation being made are checked for correctness. .. [1] Check `Case Studies`_ for real cases where the algorithm works better than what is implemented in other applications. Multiple Interfaces ------------------- Smart has multiple native and completely integrated interfaces: - Command line interface, with several useful subcommands: update, install, reinstall, upgrade, remove, check, fix, download, search, and more. - Shell interface, with command and argument completion, making it easy to perform multiple operations quickly using a local or remote terminal. - Graphic interface, offering the friendliness of visual user interaction. - Command line interface with graphic feedback, allowing one to integrate the power of command line with graphic environments. Besides these interfaces, ksmarttray is also included in the Smart package. It notifies users about available updates using a KDE tray icon. Channels -------- Channels are the way Smart becomes aware about external repositories of information. Many different channel types are supported, depending on the backend and kind of information desired: - APT-DEB Repository - APT-RPM Repository - DPKG Installed Packages - Mirror Information - Red Carpet Channel - RPM Directory - RPM Header List - RPM MetaData (YUM) - RPM Installed Packages - Slackware Repository - Slackware Installed Packages - URPMI Repository Priority Handling ----------------- Priorities are a powerful way to easily handle integration of multiple channels and explicit user setups regarding preferred package versions. Basically, packages with higher priorities are considered a better option to be installed in the system, even when package versions state otherwise. Priorities may be individually assigned to all packages in given channels, to all packages with given names, and to packages with given names inside given channels. With custom priority setups, it becomes possible to avoid unwanted upgrades, force downgrades, select packages in given channels as preferential, and other kinds of interesting setups. Autobalancing Mirror System --------------------------- Smart offers a very flexible mirror support. Mirrors are URLs that supposedly provide the same contents as are available in other URLs, named origins. There is no internal restriction on the kind of information which is mirrored. Once an origin URL is provided, and one or more mirror URLs are provided, these mirrors will be considered for any file which is going to be fetched from an URL starting with the origin URL. Mirror precedence is dynamically computed based on the history of downloads of all mirrors available for a given origin URL (including the origin site itself). The fastest mirrors and with less errors are chosen. When errors occur, the next mirror in the queue is tried. For instance, if a mirror `http://mirror.url/path/` is provided for the origin `ftp://origin.url/other/path/`, and a file in `ftp://origin.url/other/path/subpath/somefile` is going to be fetched, the mirror will be considered for being used, and the URL `http://mirror.url/path/subpath/somefile` will be used if the mirror is chosen. Notice that strings are compared and replaced without any pre-processing, so that it's possible to use different schemes (ftp, http, etc) in mirror entries, and even URLs ending in prefixes of directory entries. Downloading Mechanism --------------------- Smart has a fast parallel downloading mechanism, allowing multiple connections to be used for one or more sites. The mechanism supports: - Resuming - Timestamp checking - Parallel uncompression - Autodetection of FTP user limit - Cached file validation and more. At the moment, the following schemes are nativelly supported: - file - ftp - http - https - scp Additionally, the following schemes are supported when pycurl is available: - ftps - telnet - dict - ldap Removable Media Support ----------------------- Smart Package Manager implements builtin support for removable media (CDROMs, DVDs, etc) in most of the supported channel types. The following features are currently implemented: - Mountpoint autodetection - Support for multiple simultaneous media drives - Medias may be inserted in any order - Installed system is guaranteed to maintain correct relations between media changes - Remote removable media support using any of the supported schemes (ftp, http, scp, etc) ------------- Running Smart ------------- Smart Package Manager may be run in many different ways, depending on the interface in use and on the intended goal. The following command would install the `foobar` package, for instance:: smart install foobar While the following command would install the `foobar` package, but with graphic output:: smart --gui install foobar To open the graphic interface in interactive mode, one may simply run:: smart --gui Similarly, the following command would open the shell interface:: smart --shell Extensive help is available for all commands, by using the `--help` switch:: smart --help smart install --help smart channel --help ... -------------- Building Smart -------------- Dependencies ------------ :Core: Smart is written in Python, with some core modules rewritten as C extensions for memory savings and performance gains. With that in mind, the core system of Smart depends on Python 2.3 or higher, and a C compiler to build the extensions. :Graphic Interface: The "gtk" graphic interface depends on `pygtk` 2.4 or higher. The "qt" graphic interface depends on `pyqt` 3.3 (not 4.x). :RPM backend: The RPM backend depends on the Python `rpm` module of RPM 4.4 or higher, due to a limitation which was present in previous versions of the `ts.dbMatch()` method, and the availability of the `readHeaderFromFD()` function. In the `contrib/patches/` subdirectory there are patches for previous RPM versions including the missing functionality. There are also pre-packaged binary versions which include the patched module without requiring changes in other tools. :DPKG backend: There are no extra dependencies besides DPKG itself. :Slackware backend: There are no extra dependencies besides the packaging scripts `installpkg`, `upgradepkg` and `removepkg`. ------------ Case Studies ------------ In this section will be described real cases showing `Smart` behavior in comparison with other tools, or handling unusual situations. Notice that Smart was not tuned to work in any of these cases, and the reason it works is because handling unusual situations was the initial project goal. Case 1 - APT ------------ This case happened in a real world environment where a weakness in the algorithm used by `APT` (which is the same used in `APT-RPM`) turned a simple operation into a problem of obscure results. Smart Package Manager was used in the same environment to show its results. The problem starts when an installation of `xscreensaver` is tried:: [root@damien:/root] apt-get install xscreensaver Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: xscreensaver: Depends: libglade-2.0.so.0 Depends: libxml2.so.2 E: Broken packages The error shown makes the user believe that `libglade-2.0.so.0` and `libxml2.so.2` are not available. That's not the case:: [root@damien:/root] apt-get install libxml2 Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libxml2: Depends: glibc-iconv but it is not going to be installed E: Broken packages Another misguiding error message. Let's go further:: [root@damien:/root] apt-get install glibc-iconv Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: glibc-iconv: Depends: glibc-gconvdata (= 2.3.3) but 1:2.3.2-586_1cl is to be installed E: Broken packages Version `2.3.3` is needed, but `1:2.3.2-586_1cl` is to be installed. This message is mostly correct. The only problem is, "1:2.3.2-586_1cl" is already installed:: [root@damien:/root] apt-cache policy glibc-gconvdata glibc-gconvdata: Installed: 1:2.3.2-586_1cl Candidate: 1:2.3.2-586_1cl Version Table: *** 1:2.3.2-586_1cl 0 100 RPM Database 0:2.3.3-69473cl 0 500 file: conectiva/all pkglist The problem was found. A package from another repository (586_1cl shows it's not native, in that specific case) has a higher epoch than the one available in the usual repository. This clearly shows that the APT algorithm marks a single version as candidate, and when this is not the wanted version for some operation, the whole operation is compromised. When testing `Smart Package Manager` in the same environment, the expected result is obtained:: [root@damien:/root] smart install xscreensaver Updating cache... ######################################## [100%] Computing transaction... Downgrading packages (1): glibc-gconvdata-0:2.3.3-69473cl.i386 Installing packages (4): glibc-iconv-0:2.3.3-69473cl.i386 libglade2-2.4.0-68154cl.i386 libxml2-2:2.6.13-67598cl.i386 xscreensaver-4.15-69825cl.i386 Confirm changes (Y/n)? Smart correctly selected `glibc-gconvdata` for downgrading as the only possibility of performing the user requested operation. Case 2 - APT & YUM ------------------ This is another real case, and is being reproduced in a controlled environment for tests with YUM, APT-RPM, and Smart. The issue is, a package named `A` requires package `BCD` explicitly, and RPM detects implicit dependencies between `A` and `libB`, `libC`, and `libD`. Package `BCD` provides `libB`, `libC`, and `libD`, but additionally there is a package `B` providing `libB`, a package `C` providing `libC`, and a package `D` providing `libD`. In other words, there's a package `A` which requires four different symbols, and one of these symbols is provided by a single package `BCD`, which happens to provide all symbols needed by `A`. There are also packages `B`, `C`, and `D`, that provide some of the symbols required by `A`, but can't satisfy all dependencies without `BCD`. The expected behavior for an operation asking to install `A` is obviously selecting `BCD` to satisfy `A`'s dependencies, on the other hand, `YUM` and APT fail to deliver that as a guaranteed operation, as is shown below. First, let's see how YUM deals with the problem:: [root@burma ~]% yum install A Setting up Install Process Setting up Repo: localpub repomd.xml 100% |=========================| 951 B 00:00 Reading repository metadata in from local files localpub : ################################################## 5/5 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for A to pack into transaction set. A-1.0-1cl.i386.rpm 100% |=========================| 1.0 kB 00:00 ---> Package A.i386 0:1.0-1cl set to be installed --> Running transaction check --> Processing Dependency: libD for package: A --> Processing Dependency: libC for package: A --> Processing Dependency: libB for package: A --> Processing Dependency: BCD for package: A --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for D to pack into transaction set. D-1.0-1cl.i386.rpm 100% |=========================| 1.0 kB 00:00 ---> Package D.i386 0:1.0-1cl set to be installed ---> Downloading header for C to pack into transaction set. C-1.0-1cl.i386.rpm 100% |=========================| 1.0 kB 00:00 ---> Package C.i386 0:1.0-1cl set to be installed ---> Downloading header for B to pack into transaction set. B-1.0-1cl.i386.rpm 100% |=========================| 1.0 kB 00:00 ---> Package B.i386 0:1.0-1cl set to be installed ---> Downloading header for BCD to pack into transaction set. BCD-1.0-1cl.i386.rpm 100% |=========================| 1.0 kB 00:00 ---> Package BCD.i386 0:1.0-1cl set to be installed --> Running transaction check Dependencies Resolved Transaction Listing: Install: A.i386 0:1.0-1cl Performing the following to resolve dependencies: Install: B.i386 0:1.0-1cl Install: BCD.i386 0:1.0-1cl Install: C.i386 0:1.0-1cl Install: D.i386 0:1.0-1cl Is this ok [y/N]: YUM selected **all** packages for installation, even though `BCD` alone would satisfy `A`'s dependencies. Let's see how APT deals with that:: [root@burma ~]% apt-get install A Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: B BCD The following NEW packages will be installed: A B BCD 0 upgraded, 3 newly installed, 0 removed and 0 not upgraded. Need to get 0B/4055B of archives. After unpacking 0B of additional disk space will be used. Do you want to continue? [Y/n] n As a coincidence, APT did a better job, and selected only `B` and `BCD` to satisfy `A`'s dependency, which is still not right. Now, let's see how Smart would solve the problem:: [root@burma ~]% smart install A Updating cache... ######################################## [100%] Computing transaction... Installing packages (2): A-1.0-1cl@i386 BCD-1.0-1cl@i386 2.7kb of package files are needed. Confirm changes (Y/n)? Smart correctly selected only `BCD`, since it's necessary anyway, and solves all dependencies. Case 3 - APT & YUM ------------------ That's another interesting case which was tested with APT-RPM and YUM. In this case, there's a package `A` version 1.0 installed in the system, and there are two versions available for upgrading: 1.5 and 2.0. Version 1.5 may be installed without problems, but version 2.0 has a dependency on `B`, which is not available anywhere. In this case, the best possibility is upgrading to 1.5, since upgrading to 2.0 is not an option. Let's see how APT reacts to this situation:: [root@burma ~]% apt-get upgrade A Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back A 0 upgraded, 0 newly installed, 0 removed and 1 not upgraded. APT seems to refuse to upgrade `A`, even though version 1.5 might be installed without problems. What happens when forcing APT to install `A`:: [root@burma ~]% apt-get install A Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: A: Depends: B but it is not installable E: Broken packages It really refuses to install the newest version, and doesn't consider the possibility of using version 1.5. Now, let's see how YUM would handle it. :Update: This test case was showing the wrong results for YUM, since it was using a cached version of the package header that didn't present the missing dependency. I apologise for showing invalid results. :: [root@burma ~]% yum update Setting up Update Process Setting up Repo: localpub repomd.xml 100% |=========================| 951 B 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 809 B 00:00 MD Read : ################################################## 3/3 localpub : ################################################## 3/3 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for A to pack into transaction set. A-2.0-1cl.i386.rpm 100% |=========================| 1.3 kB 00:00 ---> Package A.i386 0:2.0-1cl set to be updated --> Running transaction check --> Processing Dependency: B for package: A --> Finished Dependency Resolution Error: missing dep: B for pkg A Just like APT, YUM selected version 2.0 and didn't consider the availability of an intermediate version. Now, let's see how Smart would behave in the same situation:: [root@burma ~]% smart upgrade Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (1): A-1.5-1cl@i386 1.3kb of package files are needed. Confirm changes (Y/n)? Smart correctly selects the intermediate version 1.5, which is the only viable possibility given the current options. Case 4 - APT ------------ This case presents the following situation: there's a package `A`, installed in the system, which depends on `libfoo`, currently being provided by `B` 1.0. What happens if `B` is upgraded to version 2.0, but `libfoo` is moved to be provided by package `C`? The expected behavior would be to upgrade `B` to version 2.0, and install `C` to satisfy `A`'s dependency. That's not what happens with APT:: [root@burma ~]% apt-get dist-upgrade Reading Package Lists... Done Building Dependency Tree... Done Calculating Upgrade... Done The following packages will be upgraded B The following packages will be REMOVED: A 1 upgraded, 0 newly installed, 1 removed and 0 not upgraded. Need to get 0B/1321B of archives. After unpacking 0B of additional disk space will be used. Do you want to continue? [Y/n] Let's see Smart in the same situation:: [root@burma ~]% smart upgrade Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (1): B-2.0-1cl@i386 Installing packages (1): C-2.0-1cl@i386 2.6kB of package files are needed. Confirm changes (Y/n)? Smart correctly selected package `C` for installation as a viable possibility of leaving `A` installed in the system while upgrading `B`. ------- Credits ------- This is the credit section, where people and institutions that have somehow contributed to the project are mentioned. :Conectiva, Inc.: Funded the creation of Smart, and its development up to August of 2005. :Canonical Ltd: Funded Smart development up to November of 2009. :Unity Linux: Smart development and deployment support. :Wanderlei Cavassin: Conectiva's research & development coordinator, who believed the project was viable and encouraged the author to work on it. :Ednilson Miura & Herton Ronaldo Krzesinski: Conectiva employees, helped setting up many distributions for tests whenever necessary. :Andreas Hasenack: Conectiva employee, helped as being the first brave pre-alpha tester, and contributed with many ideas, discussions, etc. :Arnaldo Carvalho de Melo: Conectiva board member, helped with the "channel of mirrors" idea and by encouraging the author to build a generic channel information method. :Others @ Conectiva: Many other people in Conectiva helped with ideas and alpha-testing in general during the pre-release period of Smart development. :Guilerme Manika & Ruda Moura: Ancient Conectiva employees, now board members of the Haxent company, helped by testing Smart extensively in Fedora, reporting many bugs and suggesting changes. They have also created the Smart FAQ_. :APT-RPM & Debian: Experience on packaging and ideas for a better framework were developed while the author of Smart worked as the `APT-RPM` maintainer. :Jeff Johnson: Contributed as being the RPM maintainer itself, and in many discussions regarding packaging theory in general. :Seth Vidal: YUM author, and member of the Duke University, contributed to Smart with the development of the XML `MetaData` repository format and discussions about it. :Michael Vogt: Currently the maintainer of the Synaptic, used to co-maintain it with the author of Smart. Many of his ideas ended up being adopted in Smart as a consequence. :Sebastian Heinlein: Author of the package icons for Synaptic, that were mercilessly stolen to be used in Smart's graphic interface. :TaQ/PiterPunk at #slackware-br: These guys helped Smart development by explaining details of Slackware practices regarding packaging. :Matt Zimmerman: Debian/Ubuntu developer and co-maintainer of the APT software, helped by shining some light regarding details of the `DPKG` pre-depends ordering expectations. :Mauricio Teixeira: FAQ maintenance, YaST2 channel maintainer, "tracker cleaner", general suggestions and code contributions. :Jonathan Rocker: Documentation help. .. _FAQ: http://zorked.net/smart/FAQ.html
After install with:
python setup.py build
& python setup.py install
i get the following error: Can't create datadir at /var/lib/smart/
openerp@ubuntu:$ smart --gui$
error: Can't create datadir at /var/lib/smart/,
openerp@ubuntu:
openerp@ubuntu:$ smart --version$ smart --shell
smart 1.5
openerp@ubuntu:
error: Can't create datadir at /var/lib/smart/
openerp@ubuntu:$ uname -aprecise1-Ubuntu SMP Thu Jan 15 20:22:28 UTC 2015 i686 athlon i386 GNU/Linux
Linux ubuntu 3.13.0-45-generic #74
can you help
I really need a tool to replace Synaptic PM.
Resuming downloading ? Where about it is written in detail? Will the resume work if the operation was interrupted by power off.
smart install qjackctl
complains about not finding a dependency called python:any
I think we can just remove the :any
from the package name. I have sent a pull request your way which works at my end.
Please let me know if there's anything else that may be supported.
It runs version 1.5 Tarball to deb-package
https://luna-net.or/2015/dwl/smartpm_1.5_all.deb
but what is Lintian realy mean?
I thought that "smart newer" will show upgrade-available entries for only installed packages. However, for some repo channel, I saw an entry for an non-installed package, and the installed version is "not installed".
I'm using Fedora 20 with Smart, and sometimes when I request it to install a package, the whole package manager stops responding and never comes out of it. I'd include error messages/dumps, but there don't seem to be any I'm aware of. It's been doing this since version 1.4, AFAICS.
Is there anywhere I can get screenshots of the GUIs, ie. GTK and QT. it looks like the readme says only Qt3 but I see a Qt4 option. Doe sthe Readme need to be updated?
Hi,
I have a problem running smart on Debian Jessie. It exits with the following error ( in --gui mode also ):
sudo smart update
[sudo] password for filip:
Traceback (most recent call last):
File "/usr/local/bin/smart", line 200, in
main(sys.argv[1:])
File "/usr/local/bin/smart", line 173, in main
exitcode = iface.run(opts.command, opts.argv)
File "/usr/local/lib/python2.7/dist-packages/smart/interface.py", line 53, in run
result = _command.main(self._ctrl, opts)
File "/usr/local/lib/python2.7/dist-packages/smart/commands/update.py", line 81, in main
ctrl.reloadChannels()
File "/usr/local/lib/python2.7/dist-packages/smart/control.py", line 388, in reloadChannels
if not channel.fetch(self._fetcher, progress):
File "/usr/local/lib/python2.7/dist-packages/smart/channels/apt_deb.py", line 241, in fetch
release_item = fetcher.enqueue(self._getURL("Release"))
File "/usr/local/lib/python2.7/dist-packages/smart/fetcher.py", line 180, in enqueue
item = FetchItem(self, url, mirror)
File "/usr/local/lib/python2.7/dist-packages/smart/fetcher.py", line 459, in init
self._urlobj = URL(mirror.getNext())
File "/usr/local/lib/python2.7/dist-packages/smart/fetcher.py", line 625, in init
self.set(url)
File "/usr/local/lib/python2.7/dist-packages/smart/fetcher.py", line 658, in set
user, host = urllib.splituser(host)
File "/usr/lib/python2.7/urllib.py", line 1105, in splituser
match = _userprog.match(host)
TypeError: expected string or buffer
Also, I get the same error with both Debian packaged (1.4-2) and current GitHub (1.5) version.
If you need any more info, let me know.
It appears that Smart is a Python 2-only application. As distributions aim to make Python 3 the default (such as Fedora) and only included Python release on install images, it would be excellent to have Smart ported to Python 3.
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:
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
does fail:
root@upgrade_3:~/local # smart upgrade --explain efw-endian-client
Computing transaction...[000] _upgrade()
[001] _install(efw-endian-client-4:2.9.20-0.endian30@noarch)
[002] _remove(efw-endian-client-2:2.4.30-0.endian30@noarch)
[002] _pending()
[003] _install(jobsengine-2.9.23-1.endian4@i586)
[004] _install(python-setproctitle-1.1-0.endian1@i586)
[004] _pending()
[003] _install(jobsengine-2.9.22-1.endian4@i586)
[004] _install(python-setproctitle-1.1-0.endian1@i586)
[004] _pending()
[003] _install(jobsengine-2.9.19-1.endian4@i586)
[004] _install(python-setproctitle-1.1-0.endian1@i586)
[004] _pending()
[003] _install(jobsengine-2.9.18-1.endian4@i586)
[004] _install(python-setproctitle-1.1-0.endian1@i586)
[004] _pending()
[001] _install(efw-endian-client-4:2.9.19-0.endian30@noarch)
[002] _remove(efw-endian-client-4:2.9.20-0.endian30@noarch)
[002] _pending()
[001] _install(efw-endian-client-4:2.9.18-0.endian30@noarch)
[002] _remove(efw-endian-client-4:2.9.20-0.endian30@noarch)
[002] _pending()
[001] _install(efw-endian-client-4:2.9.13-0.endian30@noarch)
[002] _remove(efw-endian-client-4:2.9.20-0.endian30@noarch)
[002] _pending()
[001] _remove(jobsengine-2.9.23-1.endian4@i586)
[002] _pending()
[003] _install(jobsengine-2.9.19-1.endian4@i586)
[004] _pending()
[003] _install(jobsengine-2.9.18-1.endian4@i586)
[004] _pending()
[003] _install(jobsengine-2.9.22-1.endian4@i586)
[004] _pending()
[001] _remove(python-setproctitle-1.1-0.endian1@i586)
[002] _pending()
Upgrading packages (1):
efw-endian-client-4:2.9.20-0.endian30@noarch [custom-r8-3]
Upgrades:
efw-endian-client-2:2.4.30-0.endian30@noarch (upgraded)
40.9kB will be used.
Confirm changes? (Y/n):
Committing transaction...
error: efw-endian-client-2.9.20-0.endian30 requires jobsengine >= 2.6.6
content of the channels is:
r6-4:
root@stan:/var/www/repo/qa/2.5/r6/4 # ls -l
total 14880
-rw-rw-r-- 1 clamav 1000 24385 Sep 13 2012 efw-dhcpd-2.9.1-0.endian7.noarch.rpm
-rw-r--r-- 1 clamav 1000 85706 Mar 12 10:18 efw-guilib-2.9.7-0.endian4.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1484559 Mar 8 13:20 efw-hotspot-2.9.54-1.endian9.noarch.rpm
-rw-r--r-- 1 clamav 1000 1485032 Mar 14 11:51 efw-hotspot-2.9.55-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1485629 Mar 20 16:25 efw-hotspot-2.9.56-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1485797 Mar 22 18:18 efw-hotspot-2.9.57-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1486082 Apr 8 11:29 efw-hotspot-2.9.58-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1486143 Apr 9 15:34 efw-hotspot-2.9.59-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1489902 Apr 16 14:33 efw-hotspot-2.9.61-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1490882 Apr 17 09:14 efw-hotspot-2.9.63-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1491034 Apr 18 11:53 efw-hotspot-2.9.64-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 834561 Mar 8 13:20 endian-artwork-enterprise-2.9.7-0.endian1.noarch.rpm
-rw-r--r-- 1 clamav 1000 834884 Mar 14 11:51 endian-artwork-enterprise-2.9.8-0.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 419 Mar 11 18:39 pkgs
drwxrwxr-x 2 clamav 1000 4096 Apr 18 17:54 repodata
r8-2:
root@stan:/var/www/repo/qa/2.5/r8/2 # ls -l
total 5272
-rw-rw-r-- 1 clamav 1000 49659 Apr 2 15:08 efw-backup-2.9.20-1.endian10.i586.rpm
-rw-rw-r-- 1 clamav 1000 71990 Mar 20 15:31 efw-base-2.9.15-1.endian27.noarch.rpm
-rw-rw-r-- 1 clamav 1000 72149 Apr 2 18:09 efw-base-2.9.16-1.endian27.noarch.rpm
-rw-rw-r-- 1 clamav 1000 3405 Mar 20 14:30 efw-demo-2.9.1-1.endian1.i586.rpm
-rw-rw-r-- 1 clamav 1000 3546 Mar 30 18:58 efw-demo-2.9.2-1.endian1.i586.rpm
-rw-rw-r-- 1 clamav 1000 57518 Apr 2 15:30 efw-endian-client-2.9.18-0.endian30.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1487605 Apr 15 19:50 efw-hotspot-2.9.60-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 1491377 Apr 19 10:22 efw-hotspot-2.9.65-1.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 15124 Apr 2 16:40 efw-interfaceeditor-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2865 Apr 2 16:40 efw-interfaceeditor-uplink-adsl-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2660 Apr 2 16:40 efw-interfaceeditor-uplink-all-2.9.2-1.endian1.noarch.rpm
-rw-r--r-- 1 root root 2893 Apr 2 16:40 efw-interfaceeditor-uplink-analog-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2870 Apr 2 16:41 efw-interfaceeditor-uplink-dhcp-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2878 Apr 2 16:41 efw-interfaceeditor-uplink-gateway-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2865 Apr 2 16:41 efw-interfaceeditor-uplink-isdn-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2874 Apr 2 16:41 efw-interfaceeditor-uplink-pppoe-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2860 Apr 2 16:41 efw-interfaceeditor-uplink-pptp-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 2884 Apr 2 16:42 efw-interfaceeditor-uplink-static-2.9.2-1.endian1.noarch.rpm
-rw-rw-r-- 1 clamav 1000 43304 Apr 11 23:42 efw-ipsec-2.9.5-1.endian7.i586.rpm
-rw-rw-r-- 1 clamav 1000 93789 Apr 12 11:41 efw-shell-2.9.7-0.endian2.noarch.rpm
-rw-r--r-- 1 clamav 1000 382795 Apr 12 19:40 efw-snort-2.9.2-1.endian20.noarch.rpm
-rw-rw-r-- 1 clamav 1000 61978 Apr 11 18:19 efw-vpn-2.9.8-0.endian14.noarch.rpm
-rw-rw-r-- 1 clamav 1000 54410 Apr 11 18:57 efw-vpnclient-2.9.7-0.endian15.noarch.rpm
-rw-rw-r-- 1 clamav 1000 486643 Apr 12 12:22 emi-2.9.15-0.endian9.noarch.rpm
-rw-rw-r-- 1 clamav 1000 309257 Apr 19 18:00 endian-core-2.9.11-0.endian11.i586.rpm
-rw-rw-r-- 1 clamav 1000 283613 Mar 19 20:33 jobsengine-2.9.22-1.endian4.i586.rpm
-rw-rw-r-- 1 clamav 1000 284365 Mar 30 15:56 jobsengine-2.9.23-1.endian4.i586.rpm
-rw-rw-r-- 1 clamav 1000 2635 May 6 18:16 pkgs
-rw------- 1 clamav 1000 19 Apr 12 19:19 pkgs.save
drwxr-xr-x 2 root root 4096 May 6 18:16 repodata
r8-3:
root@stan:/var/www/repo/qa/2.5/r8/3 # ls -l
total 31172
-rw-r--r-- 1 root root 49150 Mar 6 14:54 efw-backup-2.9.18-1.endian10.armv5tel.rpm
-rw-r--r-- 1 root root 49180 Mar 6 14:47 efw-backup-2.9.18-1.endian10.i586.rpm
-rw-r--r-- 1 root root 41903 Apr 24 18:20 efw-dnsmasq-2.9.15-0.endian18.armv5tel.rpm
-rw-r--r-- 1 root root 41909 Mar 26 11:14 efw-dnsmasq-2.9.15-0.endian18.i586.rpm
-rw-r--r-- 1 root root 57791 Apr 18 15:12 efw-endian-client-2.9.19-0.endian30.noarch.rpm
-rw-r--r-- 1 root root 57905 May 8 12:35 efw-endian-client-2.9.20-0.endian30.noarch.rpm
-rw-r--r-- 1 root root 43316 May 9 17:47 efw-ipsec-2.9.5-1.endian8.i586.rpm
-rw-r--r-- 1 root root 487043 Apr 30 12:23 emi-2.9.19-0.endian9.noarch.rpm
-rw-r--r-- 1 root root 137645 Apr 24 18:29 endian-client-2.9.18-1.endian28.armv5tel.rpm
-rw-r--r-- 1 root root 137669 Mar 29 19:00 endian-client-2.9.18-1.endian28.i586.rpm
-rw-r--r-- 1 root root 815005 May 7 18:41 freeradius-2.1.12-8.endian13.i586.rpm
-rw-r--r-- 1 root root 282245 Dec 6 08:58 jobsengine-2.9.19-1.endian4.i586.rpm
-rw-r--r-- 1 root root 29613631 May 2 16:35 ntop-4.1.0-4.endian8.i586.rpm
-rw-r--r-- 1 root root 1260 May 10 13:28 pkgs
-rw-r--r-- 1 root root 1444 May 10 13:24 pkgs+smartpm
drwxr-xr-x 2 root root 4096 May 10 13:28 repodata
After the fix:
root@upgrade_3:~ # smart upgrade --explain efw-endian-client
Loading cache...
Updating cache... ######################################################################################################## [100%]
Computing transaction...
Upgrading packages (1):
efw-endian-client-4:2.9.20-0.endian30@noarch [custom-r8-3, r8-4]
Upgrades:
efw-endian-client-2:2.4.30-0.endian30@noarch (upgraded)
Requires:
jobsengine-2.9.23-1.endian4@i586 (installed)
Installing packages (2):
jobsengine-2.9.23-1.endian4@i586 [r8-2, r8-4]
Requires:
python-setproctitle-1.1-0.endian1@i586 (installed)
Required By:
efw-endian-client-4:2.9.20-0.endian30@noarch (installed)
python-setproctitle-1.1-0.endian1@i586 [r8-4]
Required By:
jobsengine-2.9.23-1.endian4@i586 (installed)
277.7kB of package files are needed. 1.3MB will be used.
Confirm changes? (Y/n):
which then installs, because jobsengine is part of the transaction
Is this possible for smart version 1.4? I see rpm-check-signatures
can be enabled. What about signature checking for debian packages?
when smart shows "computing transaction", I firmly
I turn off the power, then turn the power back on, while the RPM of the packages is restored normally, but the SMART configuration file is completely empty and nothing else can be done. The question why smart is not stable in such situations, for me the critical question is not just the integrity of the Manager's configuration, but in principle the atomicity of any operation.
# smart query packagegroup-apps
...
packagegroup-apps-1.0-r1.24.4@all
packagegroup-apps-1.0-r1.35.6.0@all
# smart query packagegroup-apps --installed
...
packagegroup-apps-1.0-r1.24.4@all
# smart upgrade
...
No interesting upgrades available.
The problem is that smart
is rejecting the changeset by weight.
For a given changeset the calculated weight is 1.99, while empty changeset has weight 0.
Changeset
{packagegroup-apps-1.0-r1.35.6.0@all: INSTALL, kb-events-1.0-r2.4@cortexa7hf_neon_vfpv4: INSTALL, python3-msgpack-0.4.7-r0@cortexa7hf_neon_vfpv4: INSTALL, logrotate-3.9.1-r0.1@cortexa7hf_neon_vfpv4: INSTALL, hfsprogs-332.25-r0.0@cortexa7hf_neon_vfpv4: INSTALL, python-flask-0.10.1-r0@cortexa7hf_neon_vfpv4: INSTALL, python-fasteners-0.14.1-r0.0@cortexa7hf_neon_vfpv4: INSTALL, logrotate-cfg-1.0-r4@cortexa7hf_neon_vfpv4: INSTALL, python-markupsafe-0.23-r0@cortexa7hf_neon_vfpv4: INSTALL, python-gevent-1.2.1-r0.0@cortexa7hf_neon_vfpv4: INSTALL, python-werkzeug-0.11.5-r0@cortexa7hf_neon_vfpv4: INSTALL, python-itsdangerous-0.24-r0@cortexa7hf_neon_vfpv4: INSTALL, uwsgi-2.0.14-r1.0@cortexa7hf_neon_vfpv4: INSTALL, python-chacha-1+git81ee4df1020e64a93abe5fbea6b9c9dd8dc3e934-0.0@cortexa7hf_neon_vfpv4: INSTALL, python-greenlet-0.4.12-r0.0@cortexa7hf_neon_vfpv4: INSTALL, glibc-binary-localedata-en-us-2.23-r0@cortexa7hf_neon_vfpv4: INSTALL, python-pycparser-2.14-r0@cortexa7hf_neon_vfpv4: INSTALL, python-monotonic-1.0-r0@cortexa7hf_neon_vfpv4: INSTALL, python-jinja2-2.8-r0@cortexa7hf_neon_vfpv4: INSTALL, python-six-1.10.0-r0@cortexa7hf_neon_vfpv4: INSTALL, led-blink-ext-1.0-r3@cortexa7hf_neon_vfpv4: INSTALL, vlog-fix-1.0-r3@cortexa7hf_neon_vfpv4: INSTALL, share-1.0+gitrzzz-r6.2@cortexa7hf_neon_vfpv4: INSTALL, lastlog-kpanic-1.0-r3@cortexa7hf_neon_vfpv4: INSTALL, python3-pyzmq-16.0.2-r0@cortexa7hf_neon_vfpv4: INSTALL, libexpat1-2.1.0-r0@cortexa7hf_neon_vfpv4: INSTALL, libbsd0-0.8.2-r0@cortexa7hf_neon_vfpv4: INSTALL, nginx-1.8.1-r1.0@cortexa7hf_neon_vfpv4: INSTALL, root-env-cfg-1.0-r1@cortexa7hf_neon_vfpv4: INSTALL, monit-5.20.0-r3.0@cortexa7hf_neon_vfpv4: INSTALL, python-natsort-5.0.2-r0.0@cortexa7hf_neon_vfpv4: INSTALL, zip-3.0-r2@cortexa7hf_neon_vfpv4: INSTALL, python-cffi-1.5.2-r0@cortexa7hf_neon_vfpv4: INSTALL, locale-base-en-us-2.23-r0@cortexa7hf_neon_vfpv4: INSTALL, packagegroup-apps-1.0-r1.24.4@all: REMOVE}
The fix below did the trick but I'm not 100% confident it's the most correct way to fix the issue:
diff --git a/smart/transaction.py b/smart/transaction.py
index 4b90cb7..d7d8526 100644
--- a/smart/transaction.py
+++ b/smart/transaction.py
@@ -1014,7 +1014,7 @@ class Transaction(object):
else:
lockedstate[pkg] = lk
csweight = getweight(cs)
- if csweight < weight:
+ if csweight < weight or len(changeset) == 0:
weight = csweight
changeset.setState(cs)
Hi!
It was brought to my attention earlier today that Smart bundles a vulnerable copy of Expat: All versions prior to 2.4.0 are known vulnerable and Smart's copy looks like 1.95.8 of 2004 plus two backported security fixes from 2012. Please upgrade to Expat >=2.4.0, ideally latest 2.4.1. Thank you!
Best, Sebastian
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.