I’m very glad to announce the release of Listaller 0.4b today! It took over 9 months to complete this release, which is basically the result of a great lack of developers. I was working on most parts alone, since the other two developers stopped committing code because of too much work at university.
For those who don’t know: Listaller is a cross-distribution application management and software installation tool based on Richard Hughes’ PackageKit. It provides a meta package format which covers current LOKI and Autopackage setups as well as it is providing a highly flexible way to install software on different distributions needing just one package.
Listaller 0.4b got the following new features since 0.3a:
- General code cleanup: Most parts of Listaller were rewritten
- IPK1.0 standard: The package format uses a similar syntax like Debian packages use. The new syntax replaces the old XML-based files which were hard to read.
- Option to sign IPK packages: Packages can now be signed with GPG by passing the “sign” option to libuild.
- Completed PackageKit integration: We dropped the previous native package installation solution and ported all parts to PackageKit. (In previous versions Listaller connected directly to APT/Yum/Zypper etc. through an own abstraction layer. Now PackageKit is used instead.)
- New libInstaller: A library which covers all Listaller functions. This makes it possible to write more advanced frontends in other languages.
- Removed catalog support: We will do a cooperation with the PAPPI project which will remove the need of a software-store like feature. Also the distributions have very good solutions by their own now.
- Revised GUI surfaces & Qt4 GUIs
- LZMA compressed IPK packages (makes packages over 20% smaller)
- PolicyKit support for all Listaller modules
These are only the most important points. Listaller got that much changes, it is impossible to list all. While the development process of 0.4b we migrated from SVN to Git and restructured the codebase, which will make maintaining the sources a lot easier.
This Listaller release can now be used to create IPK packages for your application. The specifications aren’t stable (which was one goal of this release we couldn’t archive), but we will try to keep backward compatibility if possible. The Listaller manager is a pretty useful thing now, because it is able to remove even native packages quite well. (One of the results of our PackageKit migration) Software management systems supported by Listaller Manager are now: LOKI, Mojo, Autopackage, Natives, IPK. Support for ZeroInstall is planned.
Unfortunately there are some negative points about this release: Originally, this should have been the 0.4 release and not 0.4b. But because we don’t have enough developers, I wasn’t able to do the required tests on all distributions. So I expect a lot of bugs to be filled in the next days. The release has now been delayed for more than five months and it does not help the project to wait until everything has been tested. (Too much effort) I hope this release will bring some more developers.
The 0.4b release also means, that IPK1.0 has not been frozen: One of the goals of 0.4 was to make it API stable and freeze the IPK/IPS specifications. This is impossible at the current state. IPK is usable, but I can’t promise complete backward compatibility of all packages. (But we will try to keep the compatibility – as said before) There might be a lot of changes, as results of the cooperation with the PAPPI-Project. Also I will break the API if there are some security or stability related issues. But we will announce those changes at least two weeks before we apply them, and I guess they won’t happen very often.
One of the very positive points is the cooperation and maybe merge with the PAPPI-Project. PAPPI – short for “Personal Applikation Installer” – is a project which aims to provide a distribution neutral application marketplace for Linux. It features some old games (Atari) and Wine software as well as modern, native Linux software. At time, we’re building a roadmap for the Listaller – PAPPI cooperation. It seems like Listaller will integrate the PAPPI store and PAPPI will use IPK packages. (IPK provides some of the features already planned in PAPPIs roadmap)
Yeah, roadmap! Now, since Listaller 0.4b is out, I will focus on fixing bugs. But there already exist some plans for the upcoming major release of Listaller. Listaller 0.5 might include multi-architecture IPKs, which contain software built for multiple platforms. The appropriate binaries will be selected by the installer during installation. This might be useful for some game publishers. (Think of Ryan Gordon‘s FatELF project) Then I plan to speed up the installation and software-removal process, maybe by improving the search speed of PackageKit or by prefetching dependencies in Listaller. Release 0.5 might also include dependencies on software groups: At time, e.g. if your application depends on Qt4, you have to include every library name of Qt as dependency. In 0.5, it might be enough to tell Listaller to check if Qt4 >= 4.6.4 is installed. This will also improve the speed of installations. I also plan a C++ implementation of Listaller manager, which will integrate nicely into the KDE desktop. Well, but this are just some thoughts about the future of Listaller. A lot more important is to improve the quality of 0.4b.
If you want to try Listaller, you’ll find precompiled binaries for some major distributions (which already have PackageKit >= 0.5.6) on our Download Page. As alternative, you can compile Listaller from source code, which is available at Gitorious or as tarball on our Download Page. If you want to try some IPKs, I suggest to install the Demo of “Osmos“, a very nice indie game, packaged as IPK. You can download it from our getIPK service, which will fill up with some more IPKs next days.
If you want to help developing Listaller or have anything to tell me, please feel free to contact me! If you find any bugs, report the at our Bugtracker at Launchpad.