Possibly this should be elsewhere, eg freedesktop.org. But this is the desktop R&D section, after all ... -- MikeHearn

The problem

• Package management is not integrated with the desktop. This gives the user a highly sub-par experience compared to MacOS X and Windows, in which it is.
• There is a huge variety of packaging systems used by the systems GNOME runs on. However, they tend to be quite similar in capabilities.
• Most platforms on which GNOME runs reinvent the packaging user interface wheel, and normally do it badly. Solving it once in a high quality, usable way upstream doesn't force downstream to use it but in the cases where they do, it should provide a better experience.

First let's talk about user interfaces. Then we can discuss possible implementations.

The vision

It'd be great if GNOME users had a consistent way of interacting with the software management (install, uninstall, upgrade) process, that hid the details of what was going on. Users shouldn't have to know what [un]installation is (metaphors to real life are kind of ropey), and shouldn't have to manually upgrade software (because they never will).

There are a whole bunch of potential user interfaces. If we get this right, we could support all of them:

• Synaptic style "Do a search or type in the name, install the package from a big list"
  • Pro: easy searching if you're not sure what you want, already exists Con: overwhelming choice, mixes up appliations with random implementation details
• MacOS X style drag and drop UI
  • Pro: full marks for using drag/drop in an intuitive manner, hides concept of "install" Con: hard to implement correctly, OS X screwed it up
• Windows style "click the installer icon"
  • Pro: backwards-compatible with user expectations and training Con: kinda lame, the installer sticks around after you use it

One possible implementation of the OS X style drag/drop UI is described here. It's UI wise similar to OS X but cleaned up a bit: Apple did a botch job of integrating appfolders with the web, relying on magic "internet enabled" DMGs which automatically mount then self-destruct when saved from certain web browsers, unlike normal DMGs which don't. There's no way to tell ahead of time if one is internet-enabled or not, and of course you save a file but get a directory which then cannot be sent to another user via eg email. They also open up a raft of serious security problems because appfolders automatically integrate with the system (eg to register new url handlers) the moment they appear on the desktop. This leads to instant browser hack by design, a la Safari URL Handler holes.

The competition

MacOS X and Windows XP are the competition desktop-wise, so let's look at how they do it (kde makes no effort to integrate package management either, so we'll ignore it):

Windows has "MSI" packages, which are a bit like RPMs functionality wise but with extra desktop knobs:

• Supports install-on-demand of features. Not really a desktop feature, not actually sure this is even a good idea. Might be useful for locale data.
• Shortcuts (launchers/.desktop files in GNOME) can point to software which isn't installed yet. Running the launcher installs it automatically. I think this requires Active Directory, however this feature is apparently popular with admins. We can use it for fancier tricks (being able to email a friend a program etc).

The shortcuts feature is a good one we may wish to steal the idea of, if not the implementation. It doesn't really go beyond this though, MSI packages don't get any magic desktop integration that other programs can't. Windows also highlights the newly added menu entries to make it easier to find them.

JamesHenstridge: the shortcut stuff is handled through a "published" state for packages. The package includes information about start menu items, supported mime actions and COM components. As far as the OS is concerned, these start menu items, mime actions, components, etc are installed. The first time you do something that requires the package (select the start menu item, double click on a document that needs the app, etc), installation is triggered. This means that administrators can simply install the base OS on workstations and publish particular applications to users. Applications then get installed on desktops as they are needed.

MacOS X uses appfolders. Implementation wise we should ignore this, it's not compatible with the systems GNOME is designed for and has some major flaws anyway that make it unsuitable for all software (eg, Apples own programs like iTunes come inside custom installers). Let's look at the user interface:

• Programs are icons that can be treated as discrete objects. They can be dragged around, put on your desktop or dock etc. They resemble files at first glance.
• The object abstraction is leaky though: the desktop treats appfolders as files, but individual apps see them as directories eg you cannot drag an application onto a chat window/email to send it to a friend. Ditto for the terminal.

• Trashing an app is uninstallation. See ThreePointZero for a discussion of the "trash can as universal delete" thing.

• Upgrades are not centrally managed. There is a Software update tool but it only works for Apple programs.
• You can use a context menu option to explore inside the appfolder.

Where are we now?

Current best of breed user interfaces on Linux (and I'll use "Linux" to refer to all UNIXes like FreeBSD which resemble it package-management-wise) are:

• Synaptic: present a big list
• Click'n'run: a more refined version of above, but limited to apps and has a more website/online shop style interface

Both of these interfaces are variations on a theme, that of presenting the user with all possible software they could want. It has the google problem of "Results 1-10 of 10,000". Synaptic is even worse, it doesn't restrict the list to just applications instead displaying anything. There are people working on fixing that. Still, it's not the best UI we can do.

The basic idea is that we can link .desktop files to some abstract notion of an application, such that attempting to interact with the launcher in some way triggers automatic installation of the underlying software. Consider the example of discussing this fantastic new calculator you found with a friend on Gaim. They want to see it. Instead of sending them a URL to the website, you want to simply drag the icon from your menu onto the chat so it appears at the other end. The same technology can be used to allow drag'n'drop software installation from a web page.

The worst way to do this is to actually send the program from your computer to theirs, because:

• They may be using a different CPU arch or operating system
• They may have a mirror close to them that would shovel bits to them faster
• They may want to only install components relevant to them, eg language packs for languages they don't speak should not be downloaded
• They may want to confirm the integrity of the software and/or its author.
• They may already have it and not realise it!

A better way is to send some object that represents the software, which their desktop whether it be GNOME or KDE can magically turn into installed software. We already have an application abstraction in the form of .desktop files, so to realise this vision we need to do two things:

• Extend .desktop files to refer to a particular piece of software unambiguously
• Create a package management abstraction that GNOME can send simple high level requests like "install program XYZ", which can translate that request into a call to apt-get, pkgadd, emerge or whatever.

Let's call this abstraction the PAL

The PAL should be able to present the desktop with a list of .desktop ids for programs that have updates available, and then the desktop should be responsible (in a non-managed environment) for triggering automatic updates, meaning it can easily provide nice notifications of progress etc. The PAL should be able to take some arbitrary universally unique ID (maybe a GUID, maybe an autopackage style root name) and given an appropriate amount of time, turn it into a .desktop id that GNOME can use to highlight the menu entry/flash the panel icon/whatever.

The PAL should be able to use multiple package managers at once. This is because in reality many systems use a combination of software installation systems: 'native' packages for most things, maybe Loki style installers for commercial games and other products, a simple tarball+script for others, maybe in future autopackages or something like them. Fortunately this should not be complex: any packaging system that is semantically similar to what PAL expects should be able to register a plugin with it to provide the necessary information when asked (eg, are there any updates available?).