openSUSE 11.0: Package Management, with Duncan Mac-Vicar

n this article we will be covering all of the changes in and around the package management stack in the upcoming openSUSE 11.0. There have been a plethora of both visual and behind-the-scenes changes. We’ll also be talking to Duncan Mac-Vicar, YaST team lead, ZYpp and KDE developer, to find out a little more later.

Behind the Scenes

New Metadata

One of the major changes resulting in the lightning-fast package management of openSUSE 11.0 are the new SOLV files used now for metadata. While the classic RPM-MD (YUM) metadata in XML format is nicely readable, it results in significantly larger files and takes much longer to parse than is needed. The new dictionary-based SOLV format for repositories are up to 1/3 of the size and can be parsed in virtually an instant.

New Solver

The old solver had several problems. It was extremely slow in some cases, had a few bad design decisions, and provided bad diagnostics and suggestions if a particular case was unsolvable.

Faster

The new SAT solver by Michael Schroeder is based on expressing package dependencies as a boolean satisfiability problem. This in itself brings huge advantages as it is a well-researched problem (many example solvers available), it’s incredibly fast, and there is no need for complex algorithms. Indeed, package solving complexity is extremely low in comparison to other areas where SAT solvers are used.

To see a demonstration of just how much faster it is, see Duncan’s video comparison of the old and new Zypper.

Performs Better

Furthermore, these changes with SOLV files and the new solver have resulted in significantly better performance, with particularly reduced memory usage when compared to both Smart and YUM:

Smarter

One of the prized features of the Smart Package Manager was its ability to make smarter decisions with package management where APT and YUM fail. In particular, a few cases were proposed in Smart’s README where Smart behaves very well. So how does the new ZYpp stack do with these cases? It passes them all.

One of the other surprising yet handy features of the new package management stack is that it can be involved in hardware recommendation of packages. Want to get your webcam working? Plug it in and run zypper up for example (or with YaST) and it will try to grab all of the drivers from the online repository!

Interoperability

Patches and Patterns

One of the main advantages of openSUSE package management has been the availability of patches and patterns. Patches are small updates to fix a problem (used in the official update repository), and patterns are intelligent groups of packages which can recommend, require and suggest packages in order to make certain functionality available, without being too strict in the specific packages to install (so the more troublesome metapackage solution is not needed).

Fedora’s update metadata uses a yum plugin and a updateinfo.xml description; metadata for deltarpm availability is handled via the yum-presto plugin. In openSUSE 11.0, the package management stack reads patches from this file too! This means that you can use the yum stack out of the box, and you can generate patches using existing Fedora tools as well. Furthermore, there are continued efforts to build ZYpp and YaST on Fedora.

PackageKit

PackageKit is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distro, cross-architecture API. openSUSE 11.0 is fully PackageKit-enabled, meaning that all upstream tools across distributions using PackageKit will work perfectly on openSUSE.

See Duncan’s blog post on this for more information.

New Features

YaST

Both the Qt (KDE) and GTK (GNOME) versions of YaST have seen several changes, and in particular there are improvements to both package manager front-ends. Integration with PackageKit now means that there is a clearer view of all the package groups, with icons to distinguish them quickly:

The patterns view has also been improved:

The GTK front-end is now based on an entirely new, clean design:

Repository management can now also take place from directly inside the package manager. Just head over to Repositories -> Repository Manager. The Community Repositories module has also been integrated into here, so you can still easily select from a list of popular community repositories to add.

Updater Applets

Integration with PackageKit is tightened, with GNOME in openSUSE now using the PackageKit updater applet for all official update handling:

The KDE updater applet has now also been ported to KDE 4, and has an optional PackageKit backend.

Zypper

While Zypper is significantly faster as the result of all the previous package management changes, there have been a lot of new features added to Zypper, including:

Install remote and local RPMs seamlessly:
root:~ # zypper install http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.0/i586/filelight-1.0-7.3.i586.rpm
Reading installed packages…

The following NEW package is going to be installed:
filelight

Overall download size: 582.0 K. After the operation, additional 1.2 M will be used.
Continue? [YES/no]: y
Downloading package filelight-1.0-7.3.i586 (1/1), 582.0 K (1.2 M unpacked)
Installing: filelight-1.0-7.3 [done]

root:~ # zypper install ./banshee-0.13.2-79.i586.rpm
Reading installed packages…
The following NEW packages are going to be installed:

tango-icon-theme taglib-sharp gnome-themes gnome-audio yast2-control-center-gnome podsleuth nautilus-cd-burner nautilus metacity libssui0 libssui libgweather1
libgweather libgtop-2_0-7 libgtop libgnomesu0 libgnomesu libgnomeprintui libgnomeprint libgnomekbd libgnomecups libgnome-menu2 libgnome-desktop-2-2
libexempi3 libeel-2-2 gnome-vfs-sharp2 gnome-sharp2 gnome-settings-daemon gnome-panel gnome-mount gnome-main-menu gnome-desktop gnome-control-center
glade-sharp2 gconf-sharp2 evolution-data-server eel banshee-plugins-extra banshee-plugins-default banshee-engine-gst banshee art-sharp2 PolicyKit-gnome-libs

Overall download size: 17.0 M. After the operation, additional 70.4 M will be used.
Continue? [YES/no]:

Support for wildcards:
root:~ # zypper install *ktouch
Reading installed packages…

The following NEW package is going to be installed:
kde4-ktouch

Overall download size: 1.4 M. After the operation, additional 3.2 M will be used.
Continue? [YES/no]:
Stay tuned to opensuse.org/Zypper/Changes/11.0 for a more complete list.

Talk with Duncan Mac-Vicar

What have been the main challenges with changing major components of the package management again?

During openSUSE 10.3 we invested a lot of effort into restructuring the libzypp API so that we could actually change things. For 11.0 this paid off. We did not change any API! (just add some, like locks, and other to allow access to low level stuff, like the SAT namespace). So the challenge was to modify the classes so they act like a thin wrapper over the sat solver library. Michael Andres and Stefan Schubert did a grat job in this part. Once this was done, almost everything worked out of the box.

I would say the biggest obstacles where changing things where the basic concept also changed, like not installing product, patterns and patches anymore but use the satisfied concept. Ths pays off as a pure-rpm system, but we have to still mature the details.

There was also a lot of work for the sat solver team, who got this fast and awesome C library. The ZYpp team did a great job integrating it without many changes, but they had to add lot of features to provide all of the functionality that we had before.

What other shining features have been implemented behind the scenes?

The changes in PackageKit, which mean you can use any PackageKit application and it will use our package management engine and you won’t see the difference. Also, Delta RPMs are no longer tied to patches, they are just extra metadata in a repository, and libzypp calculates which ones it can use. This means that we could start offering delta RPMs for factory updates, for example, at any time. Also the format is compatible with yum-presto.

Our patches metadata is the same as the one used by yum, updateinfo.xml, which supports the build service strategy of building for multiple distributions. If deltarpms or update metadata is ever provided by the build service, there should be no difference if you use fedora or suse, yum or zypper. Also, if you have internal company infrastructure for generating your own updates you do not need to have two variations of this tools.

What are the plans for the future?

For the first time I think we are on the track to where we would like to be. Plans for the future include polishing, like more PackageKit work, enable user features like hardware recommends in the user interface (these features are there for years, but are not very visible), build service integration, adding semantic data, etc

---

This entry is filed under Distribution, Sneak Peeks. You can follow any responses to this entry through the RSS 2.0 feed.

Comment by christoph

2008-06-06 16:01:12

Thanks Duncan and openSUSE team! I am using RC1 and the package manager really flies
Now it is time to polish it, I would suggest the following small changes for 11.0 release:

- save search combobox entries between invokations
- ability to hide new “debugsource” packages (and save the “hide” menu settings)
- save order and width of package list header columns

And for future 11.1 release I would like to see an option to scan for unused packages (packages that have no executable bin files, and are not required by other packages), so I could clean up the mess of libraries etc. that I never use. Or better: an advanced search/filter option, where you could specify multiple search criteria, e.g. “find all installed packages that are bigger than 500kB, do not contain any bin executables, and depend on “libqt-mt”.

I used Synaptic on a friends Ubuntu machine, and felt like trapped in a cave, you could not even search for packages that depend on a specific library… but I felt a bit embrassed to see how fast it was. No longer, yast is now faster And not only this, RC1 feels faster than 10.3 or Ubuntu 8.04 as a whole!

openSUSE 11.0: KDE with Stephan Binner

With openSUSE 11.0 just a few days away, it’s time to look at one of the stars of the show: KDE. In openSUSE 11.0, you get two KDEs for the price of one. Here we’ll take a look at what’s coming in KDE, and talk to one of openSUSE’s KDE contributors, Stephan Binner.

Looking at KDE in openSUSE 11.0

---

KDE 4.0.4

KDE 4.0.4 is the version of KDE shipping with openSUSE 11.0. It’s radically different from KDE 3.5 on the surface, as well as the technology behind the scenes. Dolphin is the default file manager, a new and simpler utility for users to manage their files. (Don’t worry, Konqueror is still available for your Web browsing and advanced file management needs!)

KDE 4.0.4 on openSUSE 11.0

Systemsettings is a more usable replacement for KControl, to make system configuration much easier. KWin, the KDE window manager now supports desktop effects with KDE, easy to enable and use without loss of window manager integration or functionality.

The desktop shell and panels have been completely rewritten. The first thing KDE users will notice in KDE 4 is Oxygen, a new approach to artwork on KDE that brings a unified and attractive look to all KDE 4 interfaces, applications, icons, and themes.

After taking in the artwork, users will be able to take advantage of Plasma, the new desktop shell. Plasma provides the full desktop interface experience, from the KDE panel and menu, to desktop widgets (called Plasmoids) that offer a completely new level of functionality for KDE.

KDE 4.0 is still immature, with a few rough edges, and some of the configurability and features of KDE 3.5 are not yet implemented. KDE 4.0 was meant for early adopters, and developers porting applications to KDE 4. While the openSUSE KDE team has worked hard to polish KDE 4 and add some missing features, some users might prefer to stick with KDE 3.5. You can install both KDE 4 and KDE 3.5, so you can try the next-generation KDE out today, but fall back to 3.5 if you prefer.

KDE 4 is available on the openSUSE KDE live CD and via the DVD.

KDE Applications

KDE 4.0 doesn’t include KDEPIM (KMail, KOrganizer, Akregrator, KNode etc.), therefore openSUSE 11.0 includes beta versions of KDEPIM applications from KDE 4.1. These applications work fairly well, and will be updated to final versions via official online updates as soon as possible.

Not all KDE applications are ported to KDE4 yet, therefore KDE3 versions of applications such as Amarok, K3b, KOffice or KNetworkManager are used. They integrate pretty seamlessly. A native KDE4 NetworkManager applet is in development and will become available via openSUSE Build Service repositories.

Enhancements

The openSUSE KDE team have improved KDE 4.0 in various ways. For example it’s possible to move applets in the panel, Kickoff is polished, handling of desktop icons is improved, possibility to remove the debated toolbox/cashew via a non-gui option.

The Aya Plasma theme is used by default. If you’d prefer the official default black KDE theme it’s only a few clicks away. When using KDE 4.0 YaST2 will use an Oxygen icon theme for better integration with KDE 4.0. Furthermore YaST2 is ported to Qt4.

The new look of YaST

KDE 3.5.9

With all the talk about KDE 4, what about KDE 3.5? KDE 3.5 is the familiar, and stable, version of KDE that’s well-known and used by the majority of openSUSE users for years. Because KDE 3.5 is so popular, we’ve made sure that it’s available on the DVD media, via online network installation, and of course in the retail box set.

KDE 3.5 on openSUSE 11.0

New features in KDE3.5

Very little has changed in KDE 3.5 since openSUSE 10.3, but there are a few interesting new features. For example the KNetworkManager applet has been updated to use NetworkManager 0.7, which adds support for various advanced networking features. For example using static IP setup, or using more than one network interface card at the same time.

Improvements in KControl make it easier to select Compiz or even the KDE4 version of KWin, to provide 3-D desktop effects in KDE 3.5.

Of course KDE 3.5 in openSUSE 11.0 still boasts the host of enhancements that the openSUSE KDE team have created over the past years. For example the Kickoff menu, the Sysinfo:/ kioslave, Kerry Beagle frontend, to name just a few.

KDE 4.1

As we’ve already discussed, KDE 4.0 is still maturing and may lack features that experienced KDE users expect. However, KDE 4.1 will be much better in these respects and is expected to be released in late July. Shortly after the 4.1 release announcement, it will be available from the openSUSE Build Service repositories, enabling users to update via 1-click-install — albeit not officially supported. However, if you want to run the latest and greatest from KDE, you’ll be able to do so (and help testing as well!)

The next openSUSE release, openSUSE 11.1, should be out in December of this year and include a thoroughly tested and well-integrated KDE 4.1.x right out of the box.

---

Talk with Stephan Binner

openSUSE News: KDE 4.0.4 is the default KDE desktop in openSUSE. What made you decide to make it the default, instead of the more stable KDE 3.5.9?

Stephan Binner: There is no default desktop on openSUSE: during installation from DVD you are asked to make a choice — without default. If you use one of the installable live CDs you make the choice before the download of course.

Admitted, there exists no official live CD with KDE 3.5 (maybe someone from the community will create it?) because of resource constraints, and because we want to push people to try our KDE 4.0 based desktop. Also we want and need user feedback for the actively developed KDE series.

openSUSE News: What have been the main challenges working on KDE for openSUSE 11.0?

Much work went into making both KDE versions installable in parallel, and the applications of KDE3 work nicely under KDE4 and vice versa. That’s all the more important as not all KDE3 applications, including some maintained by openSUSE teams, have been ported to KDE4 yet. Many thoughts went also into a more granular packaging, for single application packages and to fit as many applications as possible on the live CDs.

openSUSE News: If you would highlight one detail of KDE4, what would it be?

Stephan Binner: Plasma. Because every KDE user will use it daily and the changes compared to KDE 3.5 are very visible. That’s both because it introduces new ways to interact with your desktop, panels and widgets and also because it’s the youngest of the central new KDE4 highlights (Dolphin, Kickoff and Systemsettings existed already as KDE3 versions before).

We put quite some effort into adding or back-porting features and polishing Plasma to make its feature set comparable to other non-KDE desktop shells. Plasma is also the part where the efforts which the team put into the KDE4 desktop are best distinguishable to other distributions which already shipped KDE4.

openSUSE News: Could you describe in how KDE will evolve in KDE 4.1?

Stephan Binner: Regarding the desktop KWin gains new effects and Plasma matures with introducing amongst other things a graphical way to configure panel layouts, a new approach to handle files on the desktop and a more powerful “Run Command” dialog. To learn about new features of each application best have a look at the KDE 4.1 Feature Plan and try our KDE 4.1 Beta packages in the Build Service or my KDE Four Live CDs.

Several new applications will become part of the KDE 4.1 release: kdepim 4.1 (Kontact & Co), a multimedia player (dragonplayer), a hex editor (okteta), a system log viewer (ksystemlog) and several games. You may notice that several of those are already included in openSUSE 11.0.

And not openSUSE related, the most popular KDE applications will become available on Windows and Mac platforms.

openSUSE News: And finally, any last reasons why people should install openSUSE 11.0 with KDE?

Stephan Binner: Because those two are the distribution and the desktop with the biggest momentum currently.

---

Thanks to Martin Schlander and Jeff Eklund for contributing to this Sneak Peek.

openSUSE 11.0 : Desktop Effects

openSUSE 11.0: Compiz, with Dennis Kasprzyk

There have been several changes with the Compiz setup in openSUSE 11.0, including both exciting and new features in Compiz Fusion, and extra developments behind-the-scenes which make running and managing Compiz easier. Today we will be taking a look at these, and we’ll be catching up with Dennis ‘onestone’ Kasprzyk, a Compiz Fusion core developer and openSUSE user, to find out more.

Changes in Setup

AIGLX

For openSUSE 11.0, Stefan Dirsch and the rest of the openSUSE Xorg team has worked hard to ensure that AIGLX is enabled by default for all supported hardware. This means that you can run Compiz or other desktop effects such as those in KDE 4 without having to directly enable Xgl or edit xorg.conf manually.

Compiz Fusion by Default

In openSUSE 10.3, Compiz Fusion was available in the official online repository, and the latest version with all the extra Fusion plugins has been available in the openSUSE Build Service. However, the Compiz Fusion project has matured significantly, complementing Compiz with extra plugins, a new settings configuration tool, and it is now installed by default on all openSUSE 11.0 installations.

What’s New

Simple CCSM

Compiz Fusion comes with a simple settings manager which also allows you to enable and disable Compiz in both KDE and GNOME. It can be found as the Desktop Effects application in the main menu. From here you can change general settings and not have to worry about the details. You can choose from a selection of pre-configured profiles: from anything such as minimal effects, to the full-blown “Hollywood’s got Nothing” profile, giving you countless of extra effects and plugins.

CompizConfig Settings Manager (ccsm)

Compiz Fusion now also comes with an in-depth and highly configurable settings manager: CompizConfig Settings Manager (ccsm), which is also available by default in openSUSE 11.0. From here you can change a whole horde of settings so that Compiz behaves precisely as you want, or you can even choose to enable a large selection of extra plugins providing new eye-candy or helpful other additions. Be mindful about the performance impact that this might have on less powerful computers.

New Plugins

As well as all of the previously available features in openSUSE 10.3, openSUSE 11.0 has several additions, many of which dramatically improve the accessibility of the Linux desktop. We will cover just a few of these below:

Show Mouse

With this plugin you can find out easily where your mouse is. Just hit a key-combo, and stars will start swirling around the mouse’s location:

Magnifier: Magnifying Glass

This plugin allows you to zoom a particular area of the screen without having to zoom in on the entire desktop. It is perfect when one particular area is hard to read or view:

Shelf: Scale Window Up/Down

This plugin allows you to directly scale up or down an entire window (instead of resizing it):

Brightness and Saturation

With this plugin you can adjust the brightness and saturation of any window or the entire screen.

To find out how to use this and all other plugins, simply head over the Compiz Fusion Wiki at wiki.compiz-fusion.org. For trouble-shooting and general information about Compiz Fusion on openSUSE, see the Compiz Fusion wiki page.

Latest Version in the openSUSE Build Service

Thanks to Jigish Gohil, you can always get the latest version of Compiz and Compiz Fusion in the X11:XGL openSUSE Build Service repository. In his home:cyberorg repository you can also find recent snapshots of the development tree, where you can also have direct access to a plethora of extra plugins developed by the Compiz Fusion developers. Here’s a quick preview of some of the things available in the latest version.

You can use 1-Click-Install to get the latest Compiz Fusion from the openSUSE Build Service.

Cube Deformation

In openSUSE 10.3 the cube relfection plugin was available, but now you can also distort the cube in a spherical or cylindrical shape:

You can also make the cube transparent, and even create a 3D representation of the windows:

Talk with Dennis Kasprzyk

What have been the main tasks with getting Compiz and Compiz Fusion 0.7.4 out?

After the Compiz and Compiz Fusion 0.6.0 release that included lot of changes, we decided to add only small changes and concentrate more on bugfixing and improving the window manager functionality. This is also the reason why all the 0.7.x releases are very stable even though they are only “development” releases.

On the Compiz core side, we’ve improved the window and session management, the focus stealing prevention and the handling of multiple output devices. I think that Compiz is now the window manager with the best handling of all the various Xrandr multiple output configurations. On the Compiz Fusion side, we’ve added some new plugins, features and fixed a lot of bugs. There’s too much to mention all the changes in detail here, but users can use the advanced CompizConfig Settings Manager ccsm to discover the new plugins and the new features of the existing plugins.

With simple-ccsm we now also provide a configuration tool that is more focused on end-users. It allows users to change the most needed options very easily.

What is openSUSE 11.0 like as a development platform?

There a two things in openSUSE that I really like. The first one is the Build Service. It allows me to get updated versions of a lot of packages without the need to compile them myself. The second one is the ability to directly install openSUSE with all the development packages I need. The package management provides here a very nice and easy functionality to install everything I need. But it’s also much easier to add a new system wide prefix (like /opt/compiz), than in other (debian based) distributions.

The Compiz KDE Window Decoration has really improved the integration with KDE. What other things are in store to improve the feel within KDE?

With the Compiz 0.7.6 release the KDE 4 window decorator should be ready to provide the same functionality in KDE 4.1 that we have seen with the KDE 3 window decorator in the KDE 3.x series. I’m also working on a KDE 4 kconfig backend for the libcompizconfig system. It will provide the same settings integration that we’ve seen in the KDE 3 backend. So that changing of KWin’s settings will also apply to Compiz. The biggest problem here is that the current KDE 4 global hotkey management seams to be a little buggy.

How do you see the relationship of Compiz Fusion and KWin Composite, the KDE4 Desktop effects? Do the developers in these two projects
interact?

It could be better, but it’s better than the relationship to the GNOME developers Compiz gets accepted, instead of simply being ignored with the sentence: “We have our own window manager, and we don’t care about Compiz.” For example, there was a problem with the KDE decoration API, which allows us to provide the KDE 4 window decorator, was removed in KDE 4.0. After some emails with the KWin developer we found a solution so that we have a working decorator for KDE 4.1 again.

What plans does the Compiz Fusion team have for the future?

This is hard to say. We mostly implement and release new ideas directly. Users can read our blog planet to see what is going on and will be included in the next release. I would like to see Compiz also running as pure window manager without compositing. This would also allow to run Compiz on hardware that doesn’t support compositing, or allow users to turn off compositing without the need to switch to a different window manager. We will also have a lot of work after the “object framework” merge, which will change a lot of the Compiz internal structures and the configuration system.

openSUSE 11.1: Improved Installation, Easier Administration

Welcome to the first in a series of Sneak Peeks at openSUSE 11.1! With less than a week to go until the release of openSUSE 11.1,we’ll be talking about the great new innovations included with openSUSE 11.1. To kick things off, we’ll be discussing how most people will be kicking off their openSUSE 11.1 experience: the installer.

The Installation: Building on a great base

openSUSE’s installation has long been regarded as one of the best in the Linux world. Never before has that compliment been more accurate than in openSUSE 11.1. We started by building on the great base built in openSUSE 11.0 this past summer: a sleek new look, and a simpler installation process.

New Partitioner

The updated new installer features an updated look, as seen above, but there is one very big improvement, and most users won’t even see it. It’s the new hard drive partitioner. Luckily, in most cases, the installer can recognize what needs to be done to a user’s hard disk to enable them to use openSUSE, often while keeping their previous operating system and files intact. However, many times advanced users wish to make their own custom partition table, and the improved partitioner helps them do just that.

This partitioner was the subject of usability testing, and was designed to accommodate the needs of our users.

You can also get a quick guide to the installation of openSUSE 11.1 in our Installation Walkthrough.

Help driver development with Smolt

Upon logging into your openSUSE desktop, you’ll be asked to send some hardware information to the Smolt Project. Smolt is a combined effort of Linux distributions and projects including the Fedora Project and openSUSE. Together, collecting the types of hardware in computers running Linux helps put pressure on hardware manufacturers to support Linux better, which is better for everyone.

Getting a rough estimate of the number of users for different types of hardware is also helpful to the developers of device drivers for Linux, which gives them a better idea of what drivers they should help work on to help the most amount of users. It’s one click, it helps you, it helps openSUSE, and it helps the entire Linux community!

Continual improvements to managing software

Recommended Software

openSUSE 11.1 features even more improvements to installing, removing, and maintaining software. In addition to openSUSE’s famous 1-Click Install feature, openSUSE now features a new way to discover new software.

The software manager now recommends or suggests software for your computer depending on what is already installed. These packages aren’t required by another applications, but instead extends their functionality or compliments them. It’s a fun way to discover new things you can do with your computer! Simply select the software, click Install, and the rest is taken care of.

The new KDE updater

KDE users now have a new method of keeping their computer up-to-date. Introducing the new openSUSE Updater for KDE, based on PackageKit. This new updater brings openSUSE into a cross-distro standard with PackageKit, plus enables new functionality within the updater.

The new updater still uses the openSUSE software management system, libzypp, so users still get the speed and other advantages of using our modern, state-of-the-art software management system. Advanced, modern tools wrapped up in one easy to use updating application for KDE.

GNOME users will continue to use their PackageKit-based updating application.