Log in

No account? Create an account
Installing and Updating Software Blows Goats - Technical Blog of Richard Hughes

Richard Hughes
Date: 2007-07-27 11:02
Subject: Installing and Updating Software Blows Goats
Security: Public
Installing and updating software is a really crap experience in most of the Linux distributions that I've used.

  • You run the software install as a user session as root, meaning if you start an update, and then log out, or X crashes you loose your rpmdb or equivalent installer state.
  • If you start a software update and the GUI update tool hangs you loose your rpmdb.
  • There are long "hangs" with no progress bars, at least on Fedora.
  • Every time you log in to a new user a new update tool the entire STACK is loaded, once for each user.
  • The update tools and install tools are distro specific and a PITA to maintain.
  • Most of the distro tools (yes I'm looking at pirut and pup here) suck ass from a UI and HIG point of view.
  • You can't run a update notifier, a software installer and a package query tool all at the same time.
  • The fedora ones take AGES to load and actually let me search for software.
  • All the tools ask me for a root (or user) password. I own the bloody machine, I shouldn't need to do this.
Don't get me wrong, apt is fantastic, yum is still pretty good, but the user experience is utter crap. Ubuntu are the clear winners so far, but still fail on many issues outlines above. The first thing I do when installing fedora is uninstall pup and yum-updatesd, as they are just too broken for me to use.

So rant over. What should we do about it?

Package management as a system service.

Yes, per system. When you install packages you do it as a the root user, usually for all users so it makes sense to do this in the system context. Using the new system activation stuff also allows us to start the service only when it is actually needed, i.e. when someone is trying to install something, or there is a logged in user who wants updates.

APT, yum, portage etc as backends

Yes, so users can still drop to a root shell and use the full command set of the native tool, but common stuff is abstracted over nice abstract interfaces.


Sure, then we can lock it down per user or per group on interface type, so for instance let all users in the admin group install and remove packages, but only let students query packages.

Common tools?

YES!! We choose best of breed. We have one GNOME upstream update watcher (the ubuntu one is very good) we have one GNOME software install tool for power users (synaptic is very, very good) and also a GNOME tool for end users. The ubuntu simple application chooser is also very good.


Remember this is just designed for common stuff, rather than abstract every little detail of the underlying backend. These are my ramblings so far:

as=FindPackages(s) throws NotFound()
i=GetInstalledVersion (s) throws NotInstalled()
as=GetOptionalDependencies(s) throws NotFound()
as=GetSuggestedDependencies(s) throws NotFound()
as=GetForcedDependencies(s) throws NotFound()

b=RemovePackages (as) throws OtherPackagesDepend(as), NotFound()
bas=RemovePackagesWithDependencies (as), NotFound(as)
b=InstallPackages(as) throws NotFound(as), DependenciesNotSatisfied(as)
bas=InstallPackagesWithDependencies(as) throws NotFound(as)

a(sis)=GetUpdates() throws NoUpdates()
b=UpdateSystem() throws NoUpdates()

Where to go from here?

I don't know. One thing I don't know how to fix is the callbacks for percentage completeness. Do we have to make the API asynchronous? Is there interest in fixing this stuff? Am I the only person who thinks the current bodges are insufficient for the Linux Desktop of the future? Please, leave comments (or email me) with any suggestions, corrections, or insults. Thanks.
Post A Comment | 13 Comments | | Link

User: lordmuck
Date: 2007-07-27 11:12 (UTC)
Subject: (no subject)
I'm not totally sure on the system service thing: you can't get around the transactional nature of installing software which necessitates a lock anyway, and the "can't search (etc.)" without an rpm lock could surely be fixed in other ways.

The Ubuntu experience is vastly better than Fedora in many ways, I don't think it suffers half the issues you mention, plus they can upgrade the whole distribution. Package management still feels like a pain on Fedora, but I don't think it's the concept, it's just the implementation.

I moved from yum to smart a while ago, and even including the terrible cache loading time, it's miles better.
Reply | Thread | Link

User: kevin_kofler
Date: 2007-07-27 12:28 (UTC)
Subject: apt-get dist-upgrade
Upgrading the entire distribution from a version to the next with apt-get dist-upgrade just works for Fedora too. I've done both FC5->FC6 and FC6->F7 upgrades on my laptop (with many packages installed) that way and it just worked. (OK, for FC6->F7 you should check /etc/fstab, /etc/grub.conf and /boot/grub/device.map for references to hd* and change these to sd* because of libata, and I did that, but that's pretty much it.)
Reply | Parent | Thread | Link

User: lordmuck
Date: 2007-07-27 12:46 (UTC)
Subject: Re: apt-get dist-upgrade
It doesn't "just work" for Fedora, though. It works for some people, for most it partly works to some degree.

Manual intervention for libata is one example, doing FC6->F7 can also break stuff like your i3945 wifi driver and your Xorg (I know, I did it not two days ago).

If you know what you're doing, it's possible to upgrade the package set, fix the breakages, and figure out what (if any) packages you're missing and/or should otherwise be removed. But that's not a "just works" system upgrade like Ubuntu basically have.

In Ubuntu, if an upgrade fails, it's a bug. In Fedora, it's not supported. That's a big difference IMHO.
Reply | Parent | Thread | Link

User: kevin_kofler
Date: 2007-07-27 12:54 (UTC)
Subject: Re: apt-get dist-upgrade
> Manual intervention for libata is one example, doing FC6->F7 can also break stuff like your
> i3945 wifi driver and your Xorg (I know, I did it not two days ago).

If you installed proprietary drivers, you're on your own (though if you get them in RPM form from a third-party repository and have the F7 version of the repository configured, it should have worked too, unless it was right in the window between a kernel upgrade and the kmod rebuild, a problem which isn't limited to dist-upgrades).

Was that X.Org X11 problem per chance also related to a proprietary driver?

I've also read several stories about Ubuntu dist-upgrades completely messing up the system (a problem I've never had happen to me on Fedora).
Reply | Parent | Thread | Link

User: lordmuck
Date: 2007-07-27 13:05 (UTC)
Subject: Re: apt-get dist-upgrade
No, it was the free intel driver.

I've read stories about Ubuntu's dist-upgrades failing, too. Only in Ubuntu, they call them 'bug reports'.
Reply | Parent | Thread | Link

User: mattdm
Date: 2007-07-27 11:45 (UTC)
Subject: check out what's going on with yum-updatesd
Reply | Thread | Link

User: bogado
Date: 2007-07-27 12:57 (UTC)
Subject: Please don't touch the password query...
Users should be asked for a password if they are installing something. Let me say that again, I know it can be considered a pain in the ass, mainly if you come from a windows world. But just look at what that police made with windows, to many virus use the clicking faster than thought habit to install them selves, the password prompt is harder and forces people to think about what they are doing.

I know it is not perfect, and the way it is implemented right now could create a "type a password faster then thought" habit in linux users, mainly because every trivial change to the system requires one, even for instance to set the clock.
Reply | Thread | Link

User: mattdm
Date: 2007-07-28 18:02 (UTC)
Subject: Re: Please don't touch the password query...
What about the case of installing signed packages from a pre-approved repository?

In some ways, that's less risky than changing the clock. (A bunch of wrong timestamps might be a pain to fix.)
Reply | Parent | Thread | Link

User: halfline
Date: 2007-07-27 13:57 (UTC)
Subject: totally agree with you
there's a relevant bug here:


and a thread here:

Reply | Thread | Link

User: davidz25
Date: 2007-07-27 15:51 (UTC)
Subject: Mechanism vs. Policy
Another important point is that separating the UI bits from the actual depsolver engine gives you two advantages.

1. you can leverage D-Bus system bus activation to only load the depsolver when needed; e.g. no more useless "Starting yumupdatesd" that eats memory and makes booting slower

2. PolicyKit can be used; e.g. the default consumer desktop wouldn't require authentication if the action you're doing is only updating your OS with packages signed by the OS vendor. If you're installing unsigned packages, it would require admin passwords. If you're installing packages signed by a trusted party (e.g. the OS vendor or whatever), maybe your own password would be asked for. There are many ways this can be done; the point is that we can move away from the black/white situation where you can't do nothing unless you have the root password / admin password.

There's a bunch of other things too. It all comes down to the ever important thing of separating mechanism and policy into different processes and also having a fine-grained system for determining who can do what.
Reply | Thread | Link

User: rasker
Date: 2007-07-27 20:44 (UTC)
Subject: Smart Package Manager
Smart Package Manager meets at least some of your criteria.

1) It hasn't crashed for me yet.
2) It hasn't hung yet and if it does it doesn't seem to do anything bad with the RPMDB.
3) No Long Hangs (well occasionally but not as long as yum). It also does not update from the web as much (yum is much better than it was before)
4) Not distro specific (will work with rpm, apt etc) and has a good depsolver. It does not uninstall KDE when you remove a kde app (yum used to do this in fc6)
5) The user interaction can be improved but it works quite well as it is.
6)You can run multiple apps at the same time! I think the first one gets write access to smarts db. Write access is only neccessary to update the repository data so this is not a huge issue.
7) much faster to start up than yum and does multiple downloads at the same time which can reduce download times significantly (although the repository updater only does one repo at a time - still quite quick though)

I am a fan of course. I got fed up using yumex in fc6 and switched.

Apparently yum/yumex is faster if you keep yumupdatesd running as it updates the DB at night. Yum itself is much much faster with recent developments.

The depsolver is the key piece in Smart as it is more efficient and you end up with less to download/remove. It also tries very hard to not break your system sometimes keeping older versions of software if some component is not available.

Reply | Thread | Link

User: rasker
Date: 2007-07-27 20:47 (UTC)
Subject: Re: Smart Package Manager
Also you can usually cancel operations safely. Only when actually installing software can you not cancel.
Reply | Parent | Thread | Link

User: pryc
Date: 2007-08-01 13:04 (UTC)
Subject: +1 for this idea :-)
Hello hughsient,

I am the author of the JPack[0], a tool that tries to solve problem with packages from different approach, quite the same as Smart Package Manager[1].

I really like your idea, which aims very similar thing, but from different perspective.

So apart the thing that you are mentioning synaptic to be "very, very good", which in my personal opinion is just "good" ;) I would say that your idea have a lot of sense and I am willing to help you with it.

Michal Pryc

[0] http://www.opensolaris.org/os/project/jds/tasks/jpack/
[1] http://labix.org/smart
Reply | Thread | Link

my journal
April 2008