September 18, 2008

Extremely easy driver installation

We have something really cool in.

How it works, usecase and experience.

The usecase. I have a webcam, but it does not work, because it requires the quickcam-kmp-default package. But I don’t know that.

The webcam

Desktop

You are in your desktop. You can see in the tray the applet telling you that there are security updates to install.

Tray Icon

Now I connect the webcam to the computer:

Webcam connected

Notice the tray icon. It went from “There are security updates available” to a “hardware” icon (we will add a more visible notification too).

Tray Icon

Now you click on the icon and you see:

Install Dialog

You click install, and after 10 seconds quickcam-kmp-default is installed.

See it live

Do you want to see it live?. I did a recording of the process as a flash movie.

Background

Since openSUSE 10.1, ZYpp has the ability to recommend packages based on drivers and other useful system information. Packages can supplement any namespace, which is in turn evaluated at solving time. This allows to automatic select drivers on installation, based on the machine hardware, for example.

You could also plug new hardware, and call

# zypper up

And that would recommend you to install the right drivers.

However this functionality was not used to its own potential. What we really wanted here was to recommend packages when hardware was plugged.

With PackageKit, filling that gap was possible, as we can easily talk to ZYpp from the desktop over dbus, using an abstracted interface.

So in the last weeks, Stefan Haas implemented support for this in our PackageKit ZYpp backend. Thomas Goettlicher added the needed glue in the kupdater applet. That is, listening to added devices events, and calling PackageKit to let ZYpp recommend new hardware.

Yesterday I sat to see it working. Some small one liners prevented it to work, but after some tweaking in the PackageKit backend, it worked really well. Thanks for everyone putting the pieces together.

August 18, 2008

zypper feature: source and automatic build dependencies install

There are features that are present since some time, but people just don’t know about it. This time I will mention one that is very useful to developers.

Imagine you are a contributor to foo, which is also available to the distribution as foo.rpm. However, you install the distro from packages, but compile your foo source tree by hand. Compiling foo requires lot of packages.

zypper to the rescue. If foo is in the distribution, make sure you have the main distribution repository added, plus the source repository. Source packages have a nice feature: their Requires, are the BuildRequires of the binary package.

The source install command (si) has a -d option to install only the dependencies, and not the source package itself. So lets say we want to compile PackageKit, lets install all the compile dependencies:

# sudo zypper si -d PackageKit
Reading installed packages...

The following NEW packages are going to be installed:
  opensp openjade gtk-doc docbook_3 docbook-dsssl-stylesheets sqlite-devel

Then I can go and compile:

PackageKit> ./autogen.sh --libdir=/usr/lib64
  --prefix=/usr --enable-developer --with-security-framework=dummy 
  --sysconfdir=/etc --with-dbus-sys=/etc/dbus-1/system.d
  --enable-zypp --with-default-backend=zypp

Note, you do need the source repository added in order for this to work, otherwise zypper will not be able to find a matching src.rpm package to read the dependencies from.

April 12, 2008

openSUSE 11.0 beta

openSUSE 11.0 beta is coming. This means that all the pieces of the update stack have to be in place by then.

While reading Review: Hat Trick For Fedora 9 Beta, it caught my attention that the author says “Fedora continues to wear the innovation hat” because some of the changes described there. I did not see any killer feature openSUSE 11.0 does not have too, and a few ones are worth to highlight:

  • KDE 4 integration: No distro will ever beat openSUSE here ;-) you know that. openSUSE is a multi desktop distribution and both the Gnome and the KDE team are unbeatable. Period. (I am objective today ;-) )
  • The installation experience and look essentially remained the same from Fedora 8: Sorry guys, but YaST installer looks far cooler than in our last release. The experience is also much different.
  • except there is now support for resizing ext2, ext3, and NTFS partitions from the installer: zzzzzzz. YaST resizes partitions before Linux was invented.
  • The installer also checks for password strength for the root account: YaST in the 80’s ?
  • The new package management solution, PackageKit, is another interesting feature: openSUSE 11.0 will have native PackageKit support (the backend is upstream) and it works really well. The yum backend has no good reputation. The ZYpp backend in 11.0 inherits all the unbeatable speed of ZYpp 4.x and it is robust at the same time.

Sorry guys, the innovation hat is green. Ok, enough with articles. Lets back to 11.0 beta.

We talked about package management speed, we talked about new looks and features already. However our work around patches and patterns was still missing.

During the last weeks, we have been working on this and now all the pieces start to fall together. Click on any image to see it in full size. Also note that ugly scrollbar in the disk usage is was also fixed already.

You may remember the pattern selector:

Old Pattern Selector

New pattern selector:

New Pattern Selector

If you go to the repository view, it was a little boring. openSUSE has the Build Service, which has generated a big community of repositories. Visually, we want to make a difference to the eye if a repo is a normal repository, or the home project of a friend, or a well known repository, or may be a update repository. Result?

New repo view

The old patch view was confusing. The category column never had space for itself.

Old patch selector

So we introduced categories just like in the patterns view.

Old patch selector

There are still some details. In that view the reboot patch should not be shown in the default filter, because I don’t have the package the patch fixes installed. For some reason isRelevant() is not working there. Same with the security patch. It shows correctly the fact that the patch is satisfied, but therefore it should be hidden.

In a next post I will write a bit about how patterns, products and patches are handled now, plus other features.