| Last modified: 08 Jan 2003 | Contact: Stefan Hundhammer |
The YaST2 Package Manager |
(More screen shots at the screen shot gallery)
From SuSE Linux 8.1 on, YaST2 comes with a new, powerful package manager to manage RPMs. It supersedes the classic YaST2 single package selection and integrates the YaST Online Update (YOU) and post-installation add-on selection at the same time.
It lays the foundation for supporting multiple installation sources like a traditional set of SuSE CDs, add-on product CDs, patch CDs, FTP servers or even local directories - all of which may contain software packages to install.
Specially optimized versions were implemented for both graphical user interface (the YaST2 Qt UI) or text interface (the YaST2 NCurses UI), providing each type of user with the tool that best fits his needs.
The YaST2 package manager is not a novice tool. It is intended for advanced users and experts, but experience so far has shown that average users get their tasks done with it.
 |
 |
 |
| From the installation proposal dialog, click on software or select software from the change... menu. | Click detailed selection. | There you are. |
What's new? Just about everything. It's a complete rewrite of all the package handling in YaST2, both backend (the internal data base handling) and front end.
Since this part of YaST2 is now split up into two independent binary versions, we were able to optimize both versions for their respective environments: The Qt version for the graphical environment and the NCurses version for pure text environment.
This affects dialog layout as well as keyboard usage. A text based application simply cannot display as much information at a time as a graphical user interface, but it can do things differently to make best use of what is available. On the other hand, the Qt version is no longer restricted to what will fit on a 25x80 text screen.
You now get the optimum for each world.
 |
 |
You can now easily make sure any package you really don't want on your machine doesn't get installed through the back door: Set it to taboo.
If you select other packages that require this package, you will get a message informing you about that - it will not automatically be installed as would normally be the case. This way you can make sure you don't get any, say, KDE or X11 packages on your system if you don't want that: Set some basic components of either to taboo (e.g., kdecore, kdelibs) and resolve any arising dependency conflict with don't install this - that's it.
If any dependency problems arise (read here why sometimes this is inevitable), you will get a dialog containing all of them at the same time - along with suggestions how you could resolve them. You are no longer required to resolve each individual dependency problem in sequence: You determine the sequence how you wish to do that.
 |
 |
 |
Of course you can click on a package status to cycle through all available values. But you can as well use the context menu (click the right mouse button) and select the appropriate status right away.
This way you can easily avoid dependency problems if you clicked one status too far: Dependency problems are very likely if you set a package to delete.
 |
 |
For explanatory reasons, the context menus also include automatic states you cannot select manually. |
Hit the [+] key, and the current package will added to your installation: If it is not installed yet, it will be installed. If it is installed and there is a newer version, it will be updated. Logically, the [-] key has the opposite effect.
In any case, the cursor will jump to the next package, so you can easily add or remove a number of packages in the list. If you do that for zzz All in the RPM group tag view, you can do that with all packages.
Similarly, the [>] key will update everything worth updating (any package where newer a version is present on the installation medium) and silently skip everything else. The [<] key reverts that.
Of course there is still the space bar that cycles through all available package states.
Packages that are available in a newer version than the one installed on your system are displayed in blue. Packages on your system that have higher version numbers than those available on the installation media are displayed in red.
Of course this is not 100% fool-proof (read here why - some versioning schemes are just too weird to be evaluated automatically), but it can give you a hint to take a closer look.
You know best which part of all the information is most important to you, so resize the subwindows to optimize that part's display.
When you select a higher-level RPM group, you now immediately see all packages in that category: A click on Development now immediately shows all packages for development. Of course you can still refine that by selecting a subcategory like Libraries or C and C++ - but you no longer have to.
In addition to that, there is a special entry zzz All (all the way down the group tag tree) that displays all available packages.
You can now add or remove entire add-on selections like multimedia or development after installation.
Plus, you can now see what exactly each of those add-on selections contains by clicking on it - and of course you can install or remove each package individually.
For advanced users:
 |
 |
For the really advanced users:
 |
 |
Use this to switch between different versions of the same package on all of the (possibly many) attached installation sources. Remember, there may be any number of them. The automatic will usually pick the best one for you, but you can install another version if you really want.
In addition to the classic search options, you can now specify wildcards ("*", "?") and regular expressions.
 |
 |
In any of the lists, you can jump to the next package by typing the beginning of its name: "K" gets you to the first package that begins with "k", "kde" to the first package that begins with "kde" etc.
OK, we only found that out by accident - this is standard Qt behaviour. TrollTech did that for us. But since few people seemed to know we thought it might be a good idea to make this more widely known.
If dependencies can be resolved automatically, the YaST2 package manager will do that. If a package you select for installation needs another package which in turn needs other packages, it will automatically select those packages for installation (thus the package status AutoInstall). If you deselect the first package and you no longer need the dependent packages, that AutoInstall status will disappear just as automatically.
But there are cases where this doesn't quite work out like that:
Bottom line: Conflicts exist. There is no use hiding that fact. It's how the user can deal with them what matters, and we elected to give him choices and support him as good as possible.
Version numbers in open source software come in many shapes and sizes. Most of them adhere to classic schemes like "1.23" or "1.23.45", but there are others. Even worse, every now and then there is the need to package CVS snapshots that don't have real version numbers but something with a date attached - like "CVS20020919". Comparing two such CVS snapshot versions against each other is trivial, but how does "CVS20020919" compare to, say, "1.23.45"? Which version is newer? You can never reliably tell. Only the author of that software knows for sure which version was released when.
And those are just the trivial cases. Every once in a while, software authors decide to throw their versioning scheme completely overboard - and begin with, say, "1.0" again when earlier versions already were at, say, "7.42".
RPM includes a feature for artificial version numbers for such pathological cases - and of course we at SuSE strive to make best use of that. But we cannot and don't want to prevent users from installing packages from other sources - such as homemade from sources from the Internet or even third-party RPMs.
There has been talk about distributors enforcing naming schemes. Not only is this naive to the highest degree (we cannot force the authors of free software to do anything they don't want), it is even contrary to the spirit of open source. The authors and the community make such decisions, not distributors.
There has been confusion why anybody would need or even want to search for libraries.
Normally, you don't need to do that: Packages provided by SuSE contain all the required information so the package manager will automatically resolve all dependencies and install required additional packages that contain libraries or other dependent files.
This feature comes handy, however, if you download source packages from the Internet and build them manually: The configure scripts that normally come with such source packages will tell you what libraries are required that you don't have installed yet. It doesn't (and cannot) tell you, however, what package you need to install to get that library - those things are just too system specific. Even if all Linux distributions would agree on uniform packages to handle that, there would still be completely different *ix type operating systems that handle that differently on which the same configure scripts also need to work. Thus, it makes perfect sense to have a search feature in the package manager that can tell you that.
Agreed, not every user will need that. But then, this is perfectly normal: Statistics show that 80% of all users usually don't need more than 20% of the overall feature set - for software of most every kind. This is not Linux or even SuSE specific.
Next: The screen shot gallery