Ubuntuland

What motivated you to start the PackageKit project?

Richard Hughes: Every distro re-invents the same type of package-management tools, and generally does it badly. Package management front ends are nearly always badly localized and translated as they are distro specific. Fedora has pup and pirut, Ubuntu has gnome-app-install and update-manager, and Suse has libzypp command line tools and the zen updater. The other distros basically throw some kind of GUI on top of the package tool rather than look at the use-cases and user interaction studies. To compete with Windows XP and OSX we need to improve what we offer for Linux, even with the wildly different systems such as gentoo with ebuilds and Fedora with binary rpms.

Robin Norwood: I couldn't agree more. Also, I'd add that application developers who want to install add ons but still play nicely with a distributions packaging system could benefit from a unified packaging API.

Could you elaborate a little bit about the work you've done with user interaction studies and use-cases?

RN: Personally, my only contribution to UI is to say what I don't like. I do know that, like a lot of open source projets, we could really use some UI/interaction experts.

How does it differ to the existing solutions?

RH: PackageKit works with distribution specific loadable modules and tries to abstract as much as possible between different distributions and packaging formats. GNOME and QT frontends talk to the daemon in a fully localized way, and do not require one "root" password to do most tasks.

The PolicyKit authorization to do tasks is fine grained, which means different users or groups can be authorized to do automatic updates, or install and remove packages. You can also run multiple instances of the front end tools without any "Another application is currently accessing package information" locking problems, and still continue to use the rpm and yum command line tools.

What work still needs to be done for it to reach a state where you feel its achieved its initial goals?

RH: The daemon needs to be faster. We are working on a new daemon where all interactions should be an order of magnitude faster. The front ends need to be complete and to comply to desktop HIG standards, and pushed upstream to be integral GNOME and KDE components. Projects like OpenOffice.org also need to hook into libpackagekit and use it to automatically install stuff like clipart if it's not installed.

RN: I think we also need to direct some attention to repository management. We have some tools, but it's not quite there yet. After that... polish. Lots and lots of polish. Making sure error messages are sensible, the UI is sane and helpful, and that everything Just Works.

That projects like openoffice.org will be able to work directly with the package manager is quite an exciting prospect. Has work started on this or is there much interest from upstream about this?

RN: I think it's something that a lot of application developers have wanted for a long time now, but we haven't really contacted them directly about this yet because we don't have all the tools and best practices in place quite yet.

RH: No, nothing yet. I'm hoping it will first be patched on the distro level like pulse audio was, and then pushed back upstream. I would imagine projects like scribus might be quicker to adopt this than openoffice.org.

How do you see this project in relation to others that have attempted to solve this problem, i.e. Klik (which has version 2 under development)?

RN: Well, first I should say I'm not terribly familiar with Klik. It looks interesting, but is a little bit different from what PackageKit is all about. The Klik idea seems to be 'one program, one file', sort of like Mac OS X's application bundles. This is an interesting idea, but it doesn't really work within the operating system's package management system at all. You have to have an entirely different system for getting security fixes and updates, for one thing. I have no idea how well the Klik folks have succeeded at this, but I think a solution that works within the powerful package management systems that Linux distributions already have is required.

Other projects, like Smart PM, take things from another angle. Smart tries to replace other package managers like yum wholesale. I think the problem you run into there is, until Smart or something like it replaces all of the features of the package manager it wants to replace, it will be almost impossible to get it into a given distribution. PackageKit sits on top of the existing package manager (like yum), which makes it a lot easier to gain acceptance. Power users can still drop down to yum and use that one magic feature that they must have that PackageKit doesn't provide a UI for.

I think PackageKit has hit the sweet spot between those two options.

How's the work going on getting this ready to be easily available for Fedora 9?

RH: Well, PackageKit and gnome-packagekit are already in rawhide, and we've heard lots of success stories. All of the core stuff works with a mostly-complete yum back end, and now we need to concentrate on optimizations and front end user interactions.

Do you ever hope to see it taken up as the default package management system in Fedora?

RH: I hope so. We'll still need pirut in anaconda for package selection, but it would be good to fully integrate PackageKit like we've done with PulseAudio and HAL.

Has their been interest from other distributions about incorporating this?

RH: Much. PackageKit is shipped by default in Foresight Linux and the GNOME Developer Kit. There's also interest from Ubuntu, openSUSE, openSolaris, Mandriva, OpenMOKO and a few more that we can't announce yet.

And perhaps, to finish, you could tell us a little bit about yourselves? What got you interested in free software originally? What do you like to do with your spare time when you're not working with computers?

RH: Well, I'm 25 years old and graduated this year from Surrey University with a Masters in Electronic Engineering. I work for a large defense company in Kent, UK. I enjoy eating good food and playing football.

My first contribution to free software was a kernel patch to fix non-UTF8 encoding on CIFS shares, and then I moved onto adding power management stuff in HAL. I then created gnome-power-manager and OHM, and then finally PackageKit. I guess working on free software gives me the feeling that I'm doing something useful and special, and is a great way to work in dynamic teams of people who are among the best programmers in the industry.

source: fedoraproject.org 

The roadmap for hardy heron has a pretty big list of features, most of them, although very important, are technical and a bit uninteresting. Some of them should have been in Gutsy but couldn't meet the schedule. Hardy Heron is going to be a Long Term Support release, so there's also going to be a lot of fixes for existing features. So without further ado, the features which I'm anticipating the most are.

Install on an existing filesystem without overwriting /home
When I moved from feisty to gutsy, I decided to do a fresh install. One of the things I had to do was back up my home folder, and when I finished installing gutsy I just copied it back onto my computer. This new feature will allow people to install the new version of Ubuntu without it overwriting their home folder.I'm sure this will come in very handy for people who like trying out different distro's.

Hardy Hardware Detection
This is more of a bug fix than a new feature. Gutsy already has excellent hardware support and the plan for hardy is even better and more robust detection of hardware. Sounds good to me.

GDM Face Browser
One of the changes I made to my gutsy is the GDM. I replaced the old one with something that allows me to just click on a picture of my username and login. This will hopefully be the default for hardy.

Auto Detection of Monitor Frequency
While I was testing gutsy beta I had to manually configure xorg.conf to get it to the right resolution. It wasn't fun. This should be a thing of the past with hardy as it will automatically detect everything for you. Huzzah!

Apt Authentication Reliability
Have you ever had an update fail for no reason? Well it actually fails because of 'transient network failures'. The aim is to make hardy more robust against these errors.

Redesign Restricted-Manager Code
They want to expand the role of the restricted manager and change it so that other distro's can share the joy.

Handling Full Disks
I've never had this problem with Ubuntu, but if your disk gets full, things can get quite ugly. They plan to add a notification and disk clean-up tool when your running low on space.

Desktop Effects
Make compiz fusion more robust and easier to use.

New Theme
Hardy Heron will be getting a shiny new theme, I hope they move away from the brown theme and choose something lighter and more fresh.

Easy File Sharing
To allow people to easily share files over a network. Not more I can say about this.

Dual/Multi Monitor Support
Currently you have to manually tweak Ubuntu if you want to use more than one monitor. They want to fix this for hardy.

Integrate Prefetch into Ubuntu
I noticed a slightly increased start up time in gutsy compared to feisty. Hardy will use file prefetch and other optimisations to speed up boot time.

Automatix-Ubuntu Team Collaboration
Automatix was extremely helpful for me in feisty. Although I don't use it in gutsy, its good that they are collaborating with the automatix team.

Single Click Install
Installing software is already pretty straightforward in Ubuntu. They want to make it even easier to install third party applications. I'm not complaining.

Apparmor Integration
This is already a part of gutsy, the plan is to increase integration to make Ubuntu even safer.

Firewall
Make it easier for users to configure their firewall.

Third Party Apt
Now when you install third party apps, you have to manually add the software repository to the sources.list. This spec makes it easy for users to install third party software and have it update automatically.

Revamped Logout Screen
They want to streamline the options you have when you click that big red button, to make things less confusing.

Better Integrated Wine
Better Wine will make it easier for Windows users to convert, thus helping to solve bug #1.

Xorg 7.3
This is one of the features that missed the gutsy deadline. This should make manual configuration of xorg.conf obsolete. Another much anticipated feature is Bullet Proof X, which will go into a graphical safe mode if anything goes wrong with X.

Slick Boot
To improve the boot and shutdown process and also make the things look nicer.

So that's my list, if there's any other features which interest you let me know.