app-install version 1 Copyright (C) 2009 Richard Hughes Copyright (C) 2009 Roderick B. Greening Copyright (C) 2009 Sebastian Heinlein = Scope = * A cross-distro database that can be used by an end user application browser rather than a package management tool * As software sources are added, new applications become available * Shared data format so that gnome-packagekit and KPackageKit can access the data * One package can contain, 0, 1, or many applications. = Past work = * gnome-app-install or Adept -- *need references and screenshots * Currently Debian and Ubuntu ship all desktop files and corrsponding icons in a separate package. The download size is 6,5 MByte and it takes 20 MByte on the disk. This package could conceivably be replaced with this one. = Design = This specification is not choosing to add extra information as package provides or package metadata. This is data that can be updated infrequently and would add significant size and complexity to the metadata. Providing this data out of band will allow the data to be shipped as a package which would be mirrored just like all the others. Another advantage of doing this out of band is that we do not need to using PackageKit for lots of small searches, and can query on the native DE groups using a fast . * This specification is designed around a single sqlite database * Applications must ship a 48x48 icon if one is provided. Other sizes can optionally provided, although this is not recommended. * Applications should not ship extra data in the database. Functionality will be increased in future versions of the standard and the database format will be expanded. The interchange format is native SQL, rather than a compressed database. This is so the information can be verified, rather than just shipping a 'binary blob' of a database file. This file is usually very well compressed in packages or tar.gz archives. This also allows using a database such as MySQL or postgresql if required. == Future == Data currently being considered is popularity (from popcon and mugshot) and OnlyShowIn DE hinting. Distros can merge in supplimental updates to this main database. As long as the main db file is up to date, the frontend should not care. = Limitations = Shipping this as a seporate package means that repositories have to manually sync this every time a new package is added to the repo. This is not expected to be done for every package as new packages in the repository can wait until the next refresh It is expected that distros add the "create" scripts in packagekit.org git, and share as much as possible of the merge and re-create logic. Where possible, this should be automated as mush as possible using public scripts or integration into the distro buildsystem. The frontend should not try to use any heuristics to detect if the database is stale or old. All this data has to be generated by the distro rather than pre-seeded. For instance, Debian can't ship the firefox logo, and firefox might be in the package firefox-bin on Ubuntu and firefox in Fedora. = Specifics= PackageKit already has a /var/lib/PackageKit/desktop-files.db file that maps all the _installed_ package .desktop files to package names and vice-versa. This is used, for instance: * We installed a package and give a list of applications to run * We remove a package and give a list of applications that are removed * We can choose the 'best' icon using a (hacky) metric to put a themed icon next to the installed package == location of the files == /var/lib/app-install/desktop.db /usr/share/app-install/icons/48x48/${application_id}.png (optional, recommended) /usr/share/app-install/icons/24x24/${application_id}.png (optional, not recommended) /usr/share/app-install/desktop/${application_id}.desktop (for Ubuntu compatibility, not recommended) == Schema == TABLE translations: STRING application_id (name of the desktop file, with no extension) STRING application_name (Name in desktop file, in locale) STRING application_summary (Comment in desktop file, in locale) STRING locale TABLE applications: STRING application_id (name of the desktop file, with no extension) STRING package_name (the package name, e.g. 'nautilus') STRING categories (Categories from desktop file, _not_ PK groups or PK categories) STRING repo_id (for adding and removal) STRING icon_name (local filename with extension, e.g. "totem-pl.png". This is required so that local theme can override upstream icon) STRING application_name (Name in desktop file) STRING application_summary (Comment in desktop file) == Possible Commands == pk-app-install-create --cache=/usr/share/app-install/cache/desktop.db pk-app-install-add --repo=livna --source=./livna/desktop.db --icondir=./livna/icons --cache=/usr/share/app-install/cache/desktop.db pk-app-install-remove --repo=livna --icondir=/usr/share/app-install/icons --cache=/usr/share/app-install/cache/desktop.db What to do in packages: PackageKit(install): pk-app-install-create livna-release(install): pk-app-install-add --repo=livna --source=/usr/share/livna-release/desktop.sqldata --icondir=/usr/share/livna-release/icons livna-release(removal): pk-app-install-remove --repo=livna livna-release(upgrade): pk-app-install-remove --repo=livna livna-release(upgrade): pk-app-install-add --repo=livna --source=/usr/share/livna-release/desktop.sqldata --icondir=/usr/share/livna-release/icons all distro specific stuff to live in backends/, but typically: yum-app-install-generate --name=livna --cache=~/livna-apps.db pk-app-install-generate --repo=livna --applicationdir=/usr/share/applications --icondir=/usr/share/icons --outputdir=./icons --cache=./desktop.sqldata == Open questions === So, what does a frontend need to do to get a "list of applications" 1. Query the uninstalled database 2. For each entry, check it's not in the installed database, if so, mark "installed", else mark "available" (does require the installed list to be kept up to date, alternatively a resolve (via IsPackageInstalled) might be inexpensive in this case) When the package is clicked on then do a SearchDetails like normal (?), and show the localised application_summary == Fedora specific == Would need to create yum script to disable all repos except 'fedora', iterate over all packages and get filelists. If filelist has .desktop, explode rpm file to temp directory and copy icons and desktop file to directory. Add desktop file to cache. Repeat. == Ubuntu specific == Already got the infrastructure to generate parse the repo and extract the desktop files and icon data, albeit uncompressed. Should be trivial to generate and ship the cache database.