[packagekit] AppInstall: Suggestion for application management with Listaller

Matthias Klumpp matthias at nlinux.org
Fri Sep 3 01:13:51 PDT 2010


Hi!
As asked on IRC, here's some compact information about what I imagine for
application management with PackageKit frontends using Listaller.
Listaller is a generic cross-distro application manager and installer for
*nix.
First I'd like to explain how exactly Listaller's uninstall projess works
at time:

Listaller scans the system application directories,
/usr/share/applications (and subdirs) and /usr/local/share/applications.
Then it creates an index of those apps in a SQLite database. Each
application gets an applicationId (appID), which is basically the path to
the desktop file without /usr and the .desktop file extension. Listaller
creates two databases: One for the system, and one for user's home. For
user's home dir, it scans some dirs in ~/.local and
~/.appfiles/applications.
While scanning the system application dir, Listaller also compares any
found new application with a blacklist entry. Applications which are
blacklisted are marked as "for advanced users". Distributors can define
which applications should be marked as advanced by extending the
/etc/lipa/blacklist or adding a "X-AllowRemove=false" key to the .desktop
file of an app. Candidates which should be marked as advanced are for
example YaST on openSUSE, the Terminal emulator or the PackageKit frontend
itself.
The Listaller frontend now reads the database content through the
Listaller library. (liblistaller for C/Pascal, liblistaller-qt for C++/Qt4)
The entries are displayed through the SQL data in the db, which contains
information about the icon, description, version, author of the app
(through special tags in .desktop file), translation etc. The current
Listaller GUIs are divided into two parts: "Shared app manager" and "My
apps manager". To detect the local apps, Listaller queries the local app-db
in $HOME o the current user. For shared apps, it uses the system provided
lib.
Apps which were marked as advanced are shown by using a checkbox "Show
advanced".
Now if the user wants to remove an application, he just needs to click
"Uninstall". The Listaller lib requires the appID to remove the
application. Listaller has some methods compiled in to detect how an
application was installed. They look like "if file XYZ exists and file ABC
contains the following line and directory .uninstall has a uninstall
script, the app was installed with MoJo >> execute the Mojo uninstall". If
the applications was installed from the distribution's repos, Listaller
will detect this as well if it was a local install. If this is the case, it
will query packagekit to detect the package and remove the application.
Otherwise it will do whatever is needed to remove the app. The only case
Listaller cannot handle is if an app was installed using "make install" :P
Currently some of these actions like removing LOKI installations
(GoogleEarth) are blocking,  but I could change this for PackageKit.

What I suggest for PackageKit frontends and for the AppInstall specs to
make use of Listaller is the following:
 * Remove the "package_name" in the db. Instead place an appID there,
follwing the sheme "pkg:<package_name>" if the package is known or
"dsk:<desktop_file_path>"
 * Divide frontends into "packages" and "applications" or provide
something else like a "show packages" checkbox to divide the two sections
visually
 * If a frontend is compiled with Listaller support, it will pass the
appID from the database to Listaller. Otherwise it will use PackageKit
directly and throw an error if there is a "dsk:" appID found or the "repo"
is "local".
 * We need a smart way to update the appDB. Maybe Listaller can do this,
it would also be able to set an "installed" key.
 * Maybe provide support for the advanced features of Listaller, like the
"advanced applications" or apps which were installed in $HOME. But this
only if someone considers it as useful.

So, that's it. I would like to have optional support for Listaller,
because the API changes a lot at time and I'd need some time to change a
few things in Listaller to make it depend on AppInstall. If we have
Listaller support in KPackageKit, we would have one frontend to manage all
apps on the system and one tool to manage everything software-related. (Of
course I would drop the current LI frontends)
What do you think?
Kind regards
   Matthias Klumpp




More information about the PackageKit mailing list