Richard Hughes (hughsient) wrote,
Richard Hughes

Installing and Updating Software Blows Goats

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 new comment


    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded