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).
Notice that this project is not a magical bridge between every distribution in the planet. Instead, this is software offering better package management for these distributions when working with their native packages. Using multiple packaging systems at the same time (like rpm and dpkg) is possible but would require packages from those systems to follow the same packaging guidelines. As this is not the case at the moment, mixing package systems is not recommended.
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. (...)
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.
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.
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.
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 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:
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.
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.
Smart has a fast parallel downloading mechanism, allowing multiple connections to be used for one or more sites. The mechanism supports:
and more.
At the moment, the following schemes are nativelly supported:
Additionally, the following schemes are supported when pycurl is available:
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: