Listaller: PK support reversed

And once again an article about the progress of Listaller. (yay!) Since we merged with Autopackage (to be specific: Autopackage merged into Listaller) we now inherited all of APs powerful tools to create cross-distro apps. The next steps are to make these programs and scripts work with the current Listaller infrastructure. This work will be done after another construction site has been finished: PackageKit inclusion, the reason for this blog post. Now you might think something like “how boring, we already did this a year ago, Listaller already uses PK with success” – This is true. But “PackageKit inclusion” this time means to include Listaller into PackageKit, to make PK use some of Listaller’s functions to handle applications.

Reason for this is basically the AppInstall project, which provides sets of data to make PackageKit frontends display applications instead of packages. PackageKit benefits a lot from this work, see this blog article by Richard Hughes for details. Already visible is Daniel’s work on KPackageKit, which is really awesome!

Now, since PackageKit frontends are able to deal with applications, there is again a lot of duplicate functionality in Listaller and PackageKit, something I really dislike as it confuses users, makes maintaining the apps more difficult and makes the work really frustrating. So I talked with the PK guys about this issue, and we decided to make PK use Listaller to handle all apps which aren’t installed via the package management or which are installed through local packages. If this is implemented, users will have one central place to manage ALL software on their computer. Also, there will be no more duplicated GUIs. KListaller will only be used to install IPK packages and if everything works fine, Listaller-GTK can be removed completely and replaced with a solution which also just provides a frontend for IPK software installations.

I also plan to make the Listaller daemon completely obsolete, so Listaller can use the PK daemon to install packages. This avoids having two daemons. All Listaller features will – of course – stay.

These changes will cause a lot of API breaks for Listaller 0.5, so we can’t keep the API stability promised between 0.4 and 0.5, there are too much good reasons to break it. Also, there’s no third-party dev I know about who actually uses the API.

We have very less developers at time, so the usual call for help after every post about Listaller: If you want to help, feel free to contact me via mail or us via our mailinglist.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.