Application Installer Miniconf: Trip Report

For three days last week I attended a conference on application installing in Germany, hosted by Vincent Untz and the other guys from Novell. There were experts sent from Fedora, Ubuntu, Debian, Suse, and Mageia. From Fedora both I and Florian Festi attended.

The idea of the conference was to talk about defining some APIs we can share, to discuss interchange formats, and talking to the UI designers to make installing and removing software on Linux suck less.

Overview:

  • Lots of progress, people were willing to help solve a common problem in a unified way.
  • The right people were at the meeting and we came up with a really good technical plan with action items.
  • Ubuntu Software Center really kicks ass, although we really need them to drop the CLA. USC will be ported to use PackageKit in the next couple of weeks.
  • Packages and packaging are not that interesting to the end user.
  • We will integrate with online social services to provide features like ratings and comments using OCS. OCS needs a couple of things added to the API, which will happen in the next few weeks
  • We will produce appdata.xml metadata per-repository, rather than one super-package.
  • I need to talk to the fedora-infrastructure guys – it might make sense to not refresh the metadata every day for the rawhide compose.
  • We will use a xapian index to query the desktop metadata, rebuilding as repos are added / removed. This supports fast stemming and other advanced features.
  • Will add several new optional fields to desktop file specification upstream for the proper solution, more details to come soon. This will allows us to search for photoshop and return gimp in the search results.
  • Non .desktop files as applications do make sense, e.g. firefox plugins as .xpi or Chromium style web links. This makes sense to push to OCS, rather than in the distro metadata.

What this means for Fedora:

  • We add a tiny script (to be written this week) to generate the xml file and the icon tarball for the distro at compose time (similar to my earlier app-install work)
  • We ship the extra optional metadata in the fedora mirrors (+~9Mb)
  • We download this in PackageKit if a repo is enabled or refreshed

We’ve put a few detailed documents with architecture plan on the wiki and Vincent has also uploaded all the notes from the meeting to the same location.

For more information still, there was a presentation we gave at the end of the conference. It’s nearly an hour and gets pretty technical, so get coffee before if you click the video.

Thanks again to Red Hat for sponsoring my travel and hotel expenses.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

19 thoughts on “Application Installer Miniconf: Trip Report”

  6. wow, finally some progress in this area! this meeting should had been held a few years back!

    but am glad it finally happened :)

  7. This is great, it’d be greater if the whole packaging system is rethought for instance the need extra dependencies(having dependencies in several package files is cumbersome). And I’m not recommending to ship all the libraries that are used by the application, instead cant we package some set of dependent packages on to one package? It’ll be built on the assumption that the target system is a stock system for example Ubuntu 10.10. This would be good for offline installations.
    IMO it will be better if the whole system gets more independent, like using bittorrent for offering packages(Just a thought, but Im sure people will seed!)

  8. So what is OCS? That link still points to a ~hour long YouTube video. I skipped through it in about 10 minutes trying to look at the slides and haven’t a clue :-)

  10. CLA: Customer Licensing Agreement?

    Any possibility of integrating something like Ubuntu’s old add/remove programs instead of the current USC? While the USC is slick, I don’t know enough about licensing.

  12. What’s the reason to drop the CLA from the Ubuntu Software Center and what does it imply?

    I’m sorry just a simple soul here, so I just want to know what the difference will be in the future, I’m using Ubuntu now…

    It does sound like a big step forward for Linux and its position among other OS’s.

    Regards

    1. Imposing the CLA on USC makes the software unsuitable to be shipped with GNOME. I don’t think I (or most of the other distro contributors who work for US companies) can sign the CLA, so it kinda makes my contributions worthless.

      The CLA basically entitles the rights holder to relicence the software without any consultation in the future. That essentially means it *could* become proprietary software. That would be really bad.

  14. Oops…another big metadata file :(
    It’d be much better if the metadata can be broken into smaller pieces; including the most basic required data in the main metadata file and download extra stuff when they are really needed (e.g. only the icons of the applications in the search result are downloaded, when required). Even if it is possible, an online service is better.
    As a fallback, it’d be nice if the metadata is provided in distribution releases (included in DVD isos for example).
    Yum already wastes lots of bandwidth… (yes, downloading 10MB data is still a waste of bandwidth for many). I’m personally going to propose & implement a new metadata store for yum after finishing my thesis; but a cross-distribution system for metadata is much harder to change when created… :((

Comments are closed.