Comments

• perhaps "Clear" or "Clear search" instead of "Cancel search". Cancel is mostly used for "get me out of here!"-actions - AndreasNilsson

• for a cleaner ui, perhaps we can show "Install" and "More Info" only when the entry is selected. The progressbar+[cancel] should show all the time it's getting installed though. - AndreasNilsson

• what happens when you do a search, starts installing and then do a new search?
  • if the backend supports non-locked queries (yum for instance) then we just do the search - if not we queue it and put up a progress bar.

    • a non-locked what? (sorry, not a coder ) I was mostly interested in what the widow did. I read the user cases again and saw that it pops up a notification.

• the biggest problem with installing software using the classic repository model is that software is rarely categorized usefully for the user. for example, if a user searches for evince, it should not just list 5 packages with various relation to evince (evince, evince-firefox, etc. etc.). it should display only "application" packages (evince) and then as clearly denoted optional add-ons, the sub-packages (evince-firefox), and not show at all the implementation packages (evince-common). this requires merely that packages can be identified as an application (or otherwise the "main" package), that a package is an add-on to another package, or that a package is some internal detail. OpenOffice is another good example. There should only be one entry in the packagekit UI for OOo. The various components of OOo should be shown merely as add-ons to OOo. the UI for this would be a bigger, prettier entry for OOo with the sub-packages being smaller entries underneath which are (maybe) hidden by default with an expander arrow, and marked for installation by default (possibly using a per-package setting) if OOo is marked for installation. if you're not going to make real improvements to the software management UI, then you might as well not bother with the UI at all in PackageKit, and just stick to the library hooks for apps to request packages, and let pirut/synaptic/etc worry about providing management UI. a bad example in your write-up above is the dialog stating that evince-firefox is removed is evince is removed; that just isn't necessary. - SeanMiddleditch

  • gnome-app-install in Ubuntu solves this by parsing all the .desktop files in the repository and putting them in a data package. That way you only get the end user apps, not the raw package names - CoreyBurger

• I have been wanting to do this for ages, I made some mockups of a simple package installer ages ago, and thought they may be of use to you: http://flickr.com/photos/29906893@N00/tags/yum. They obviously need some work to be fully functional, if your interested just let me know! - NeilJPatel

• Lets also consider the use case of adding plugins to applications. Like new stuff manager. http://www.k-d-w.org/node/3

• A D-BUS API for package management sounds nice. My question is: does PackageKit also address the problem of installing third-party apps in a packaging-system-neutral, well-integrated fashion? It would be great if ISV's would finally have a way of installing their software on the users' systems without having to create packages for every possible packaging system or distribution, and a D-BUS API may be just the right thing for that. But maybe that's a bit out of the scope of your project idea... - DenisWashington

  • Maybe adding a backend for 0install (http://0install.net/) would do the trick? I tried 0install recently and was impressed how easy it works (installing GDC - the GCC implementation of D language - was a snap and was of great value as Debian offers no such packages yet). Also it only installs packages for one user instead of system-wide, something which I find quite interesting (especially for a Desktop Linux which is mostly used by one person anyway). A backend for Klik (http://klik.atekon.de/) might be an alternative if 0install doesn't fit requirements. Of course, for good integration this would require that PackageKit supports using more than one backend in parallel (maybe abstracted as "support one system backend (like apt or yum) and multiple per-user backends (0install, klik)"). - OliverGerlich

  • The problem with a 0install backend would be the need for having 0install installed. As long as not every relevant distribution ships it, ISV's cannot rely on it to be there. But as I said, this may not be the right place to discuss this all. - DenisWashington

• Here's an article with some ideas about software updates for Desktop Linux: http://primates.ximian.com/~federico/news-2007-02.html#software-updates-for-home-users . I don't agree with everything there (automatically installing new kernel because "we can rely on the software to be tested and not having any flaws" sounds naive to me but the overall usability ideas there look great. Might be useful to design the DBUS API so that it can indeed present one single OpenOffice update instead of ten updated openoffice.org-2-xyz updates. - OliverGerlich

  • Making kernel installs manual instead of automatic isn't going to solve anything for most users if the kernel is broken. That particular can of worms needs to be solved by the boot-loader, similar to Windows Safe Mode; if the system doesn't finish booting under the new kernel, the boot loader offers to boot the old/safe kernel next time. Easy to manage with GRUB, I believe. - SeanMiddleditch

• Someday, maybe in about 25 years, we could see applications like this:

List of applications, categories and information about the selected app. Sorry about this "blasphemy" comment. -VincentVolaju

• I don't know if this enters in the philosophy of this program, but I would like that PackageKit could manage the 'repositories' too, SVN, Git, all of them. Plus: PackageKit could update another pieces of software, like Klik .cmg, that would be amazing, because this sofware could centralize update managers. -VincentVolaju

• Maybe reconsider the constraint of one backend at a time if this means not multiple types of repository on a system. Obviously you don't need both a deb and rpm backend, but being able to weave together coexisting repository systems would be cool. This could be handled through plugins and language bindings. I'm thinking about rubygems, and I would totally use an update manager that handled all my checkouts, as above. Those are geeky use cases, but supporting at least in potential the competing simple install systems would be good. -JosephMethod

  • A plugin system would be great, for example: the Klik project need something to update the .cmg files (application images), so, instead of create other way to update them, they just create a plugin for PackageKit, and problem solved, now you don't need to have several pieces of software to update all your sistem apps. -VincentVolaju