You might have heard of the AppStream project already: In short, AppStream is an effort to make software installations on Linux easier, by showing users applications instead of packages, providing a central place for software management etc. And all this is cross-distributional! (Details) – But wait: Wasn’t this the ultimate goal of Listaller?
Yes, you’re right. Listaller was started in 2007 with the goal to create a unified UI for software management, which is cross-distro. To make it clear: Listaller completely failed in achieving it. The main reasons were the very slow development, and my idea to “make it right for everyone” before doing a release. This was stupid, cause it slowed down the development process too. Also, there was less communication with the distributors. I wanted to start communication when I finished a working example of the whole Listaller concept. (Which was also not the smartest plan.) AppStream, which was initiated by famous members of three distributions, did it right from the beginning by setting up a meeting to discuss everything and make sure it is compliant to every distributor’s policy before writing any code. Also, AppStream goes far beyond what Listaller was designed for, because it solves the software management problem on a much deeper level than Listaller did.
So, you may now think “Why not drop Listaller, if AppStream does everything Listaller did?”. This is not true. AppStream does all we need for software management. But Listaller also has concepts for software installation, which includes creating distribution-independent software packages etc. This stuff definitely is valuable for AppStream too. So I started to rethink how Listaller works now, and what needs to be changed to make it ready for AppStream, and of course what IPK is missing to become the software-setup format of choice.
Development process
Listaller 0.5, which should have been released three months ago, will not be released as stable version. Instead, the 0.5 series will become some kind of unstable testing series, to check out the new features.
Also, the Listaller codebase will be split into three parts: listaller-core, listaller-devtools and listaller-gui. Splitting it up will simplify maintaining the codebase, also every bug which is fixed in “devtools” does not have to wait until I make a new release of Listaller. Listaller-core contains everything the user needs to install software using Listaller, as well as our Qt bindings, the installer command-line tools etc. Listaller-devtools will contain everything you neet to build Listaller packages, like “libuild”, “binreloc” or “visual-ldd”. Listaller-gui will the contain the GTK+ and Qt UI for Listaller.
General concepts
Although Pascal definitely is a great language, it is a bad choice for a tool like Listaller. Collaborating with other projects is difficult and we have less bindings for Pascal. So I searched for an alternative language, also to make the codebase a little bit more consistent. (Listaller currently uses four different programming languages :P) I had to choose between C++, GLib/C and Vala. Finally I decided to use Vala for the Listaller core. Vala will first only be used to rewrite the management part of Listaller, cause I would have to rewrite this anyway. The IPK-installer will remain Pascal-code, until I rewrite it too. The command-line tools will also be rewritten in Vala.
The IPK specifications offer a lot of options to software developers at time. After speaking with some AppStream devs, I was persuaded that offering less options to package maintainers is better. So, IPK/IPS will be changed to support less features and less options, which will definitely increase security of IPK. Also, the Listaller “runapp” tool will be modified to make it possible to run applications in a Sandbox by default. (This will minimize the risk of damaging the system too) I’m looking at Arkose as the Listaller sandbox at time. As consequence of the IPK changes, Listaller will take more responsibilities how to install an application, which is what distributors want. (So they just need to modify Listaller to fit their policy, instead of every IPK package doing it’s own thing) The whole dependency fetching and managing process will be rewritten too.
Hope this will throw some light on the future of Listaller. The project is definitely not dead. As always: We’re still seeking developers 😉