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 softwares try to find a possible solution to satisfy the relations involved in some user-requested operation, and sometimes even fail to do so, 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.
Check case studies for real cases where the algorithm works better than what is implemented in other softwares.
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:
- 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
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.
Smart has a fast parallel downloading mechanism, allowing multiple connections to be used for one or more sites. The mechanism supports:
- Timestamp checking
- Parallel uncompression
- Autodetection of FTP user limit
- Cached file validation
At that moment, the following schemes are nativelly supported:
Additionally, the following schemes are supported when pycurl is available:
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 guaranted to maintain correct relations between media changes
- Remote removable media support using any of the supported schemes (ftp, http, scp, etc)