144 lines
6.6 KiB
Plaintext
144 lines
6.6 KiB
Plaintext
app-install version 1
|
|
|
|
Copyright (C) 2009 Richard Hughes <richard@hughsie.com>
|
|
Copyright (C) 2009 Roderick B. Greening <roderick.greening@gmail.com>
|
|
Copyright (C) 2009 Sebastian Heinlein <devel@glatzor.de>
|
|
|
|
= 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.
|
|
|