I think many of you read the recent announcements and blog posts about “GNOME-Apps”, like this one. Initially I wanted to be at FOSDEM and attend the GNOME hackfest were this was discussed too, but university binds me here so I was unable to come (which is really unfortunate).
Some people asked me what the GNOME-App-Bundles mean for Listaller. The GNOME bundle proposal will make cross-distro application deployment for GNOME apps possible, and this essentially the same goal as the one of Listaller. So it is reasonable to question the future of Listaller when GNOME enforces their App Bundles (because most distros ship GNOME, most distros will have the app bundle support, which means people will use it because they can rely on it being present). Instead of answering the same questions again and again via private mail (remember, there is a new public Listaller mailinglist available, replacing the old Google Group) I’ll write this post.
In my opinion, there is no reason to worry about Listaller. I think the Listaller approach of app-directories and shared resources is much better than having app bundles mounted via FUSE. When Listaller was started, the Klik project already existed (Klik is dead now, Glick2 was developed by Alexander Larsson as replacement. Glick and Listaller nearly have the same age (I think Listaller might be older, when counting the first experiemnts…), so this is no case of “re-inventing” the wheel on both sides.). I initially wanted to contribute to Klik. However, FUSE-mounted app bundles have certain problems:
Listaller, on the contrary, integrates nicely with the system. Applications installed with Listaller will show up in every Software Center which uses PackageKit. The regular system updater is able to update Listaller applications as well as distribution components, and the Listaller dependency solver will always prefer distribution packages to satisfy dependencies, before falling back to other solutions. This tight platform integration is also one of the main reasons why Listaller is different from ZeroInstall (Listaller is also Linux-only, while ZeroInstall is not – both projects cover slightly different user-cases).
In order to have these advantages, Listaller requires all applications to be relocatable, while Glick2 does not require that (which is an advantage). But of course, Listaller provides a complete toolchain to make your application cross-distro-ready.
Apart from that, there are also some points the GNOME approach and Listaller have in common:
So, what do I plan for Listaller now? First of all, I will speak to the GNOME developers (already asked some questions, but no mailinglist post yet) and see their plans. Nothing is set in stone, and there are some things on the whiteboard which will be very useful for Listaller too. For example the new sandbox Greg-Kroah-Hartman and others plan to develop. I plan to use it as the one-and-only sandbox for Listaller apps, enabled be default.
Also, the plan is that GNOME apps should only depend on a certain “Framework” version, which the application bundles specify. The plans for a GNOME SDK & Framework are not exactly new, and I was expecting that. Same goes for KDE. Having apps only depend on a “Framework-Version” will simplify Listaller’s dependency solver and speed up installations. Work to support stuff like this has already been done some time ago (you could use “Framework: KDE-Platforms (==4)” as dependency, but the code for processing this is disabled, as certain stuff is still missing).
There are also some concrete plans for the next Listaller releases, which did not change at all: For the upcoming 0.5.7 release, we will provide automatic application and dependency updating. With the following 0.5.8 version, the API will be stabilized and the dependency solver will be updated (I will implement basic support for Python and advanced support for KDE libraries), so it becomes much more useful. The cross-distro software repositories will become reality. Also, I will write even more documentation. Then, the Listaller 0.6.x series will be started with increased API stability. The IPK specs are stable already and backwards-compatible, so it is safe to build packages. (post-0.5.7 is a great time to port your old Autopackage packages to Listaller!)
With regards to AppStream, the project will continue without any impact from whatever GNOME decides, since we need application-centric distribution software managing anyway. Solutions like Glick2 and Listaller only contribute 3rd-party-app installations as a new method for app deployment.
All projects around AppStream and Listaller are developing slowly, unfortunately, due to a great lack of manpower (in fact, I am the only one who pushes these projects and works on AppStream integration components, Listaller and PackageKit modules at time). However, all the hard bits are done. In March, when I have more time again, I will do some intense hacking on all components and make them work together nicely. There is also a blog series planned on how you can use Listaller as distributor/developer/user and how you can implement AppStream as software-center-developer/distributor (these will be smaller and easy-to-digest blogposts).
Also, I will continue work on Apper to support more AppStream features (Apper already provides extra Listaller and AppStream support already: Compile it with -DAPPSTREAM=ON -DLISTALLER=ON and see the magic happen. For AppStream, you need a distribution which supports AppStream, and have the AppStream-Core libraries installed. For Listaller, you need a working PackageKit>=0.8.x and – of course – Listaller). I will also work on GNOME-Software, which is planned to become a cross-distro software center for GNOME.
So, stay tuned – there will be some exciting news soon, when all the pieces are falling into place! And if you want to help, just contact me!