Listaller 0.5.4 released!

And again, a new release of Listaller is out. But this release is special, it is probably the most important Listaller release so far. I’m glad to announce the availability of the first usable release of Listaller. “Usable” in this case means that you can build Listaller packages, without having to worry that their format will change completely. We will now only do incompatible modifications if it is absolutely necessary. Usable does not mean, that every feature is rock-solid and bug-free, remember Listaller is still a very young software[1] and still a bit experimental, but you should be able to try it out without problems.

[1]: The rewrite is young. The project itself started in 2008/2009.

What is Listaller?

So, what the hell is Listaller? Listaller is a solution which will make it possible to install 3rd-party applications on Linux-distributions easily. You might say now, that we have a package-manager for this. But what do you do if your favourite package is not available in the repos? Ubuntu users will just add a PPA, and by doing this practically give someone else full root-access to their machines and potentially break system upgrades. That should never ever happen, and PPAs are therefore dangerous stuff, which is useful but should better be used by people who are aware of what they’re doing. PPAs are an overkill if you just want to have the newest version of GIMP. Right now, software relations on Linux look like this:

Lots of packages depending on each other. You can’t replace one of them without breaking the others. Listaller now does this:

Users will get a package, which provides an application. This application-package (extension *.ipk) declares dependencies on components in a distro-agnostic way. Listaller will then try to satisfy these dependencies at install-time, by downloading the right dependencies and installing them side-by-side with the native packages. By doing this, the system itself is left unaffected by the changes and application installations will only affect a very small part of the system. Therefore, Listaller packages are much more secure than native packages. Of course there are limitations: Listaller packages were designed to install 3rd-party applications. Applications for example are games, a web browser, image-editing tools etc., but not system components like PolKit or full desktop-environments. So you won’t be able to install these using an IPK Listaller package. You still have to rely on your native package manager there. But for most users, features Listaller provides are enough and might also give some additional freedom to the users as some people think. (incuding me)

So, now the cool stuff: Listaller is integrated into the system. This means that users won’t notice Listaller is there and working, because they continue using the tools they already know. There is no duplication of tools when using Listaller. Listaller is plugged into PackageKit, the cross-distro package-management abstraction layer, and frontends can communicate with Listaller using the PackageKit API. This means you can install applications using GNOME-PackageKit or Apper and they will show up just like native packages in their software managers. Even updates will be done through the system’s updater.

Of course, you can compile in additional Listaller support, for example compiling Apper with -DLISTALLER=ON will give you a nicer Listaller package installation UI, which exposes some more of Listaller’s features:

Of course, this is optional. The KDE frontends are in a really good shape right now, the GNOME side needs some love and an UI designer, but it also works.

What’s new?

So, what is new in Listaller 0.5.4? We now require that you use the DOAP RDF Format to describe the project you want to package.Most projects already provide DOAP data, and creating it is really trivial. The new release also makes it possible to embed more architectures in one package, which is especially nice for some games with small binaries and a large amout of data. They now just need to ship one package.

Listaller also allows setups to declare a “replaces” dependency on existing software. For example a IPK packaged version of Firefox could declare a replacement on “/usr/bin/firefox”, so users get a message that they might want to remove the native distribution package after they installed the new 3rd-party app. I’m not super-happy with this feature, so please use it carefully! Please note that Listaller still won’t remove any native package automatically.

It is also now easier for packages to ship license texts, they just have to link a file called “license.txt” in the IPK package source directory.

Also, options to GPGsign a package have been improved. GPGMe API is not really nice to work with, so with the improvements, the ability to check signature trust levels has gone missing, but I’ll add this again in the next release. (This check was broken anyway) That’s the reason why even signed packages now will only get a maximum trust level of “low”.

This release also contains many other improvements and bugfixes, for example we no use /var/tmp instead of /tmp for temporary data, just to make Lennart happy.

What’s missing?

Listaller needs help! After rewriting the tool, many features went missing and need to be implemented again, as well as there are some things which are planned and just not implemented because nobody did that 😉

For example, dependency resolving sucks at time, there are many parts which have to be improved. I will finish policy for dependencies soon and then this can be done properly. (by using or not using ZI feeds) First steps are already completed.

Also, there is no Listaller Updater at time, a feature which is probably one of the most important things.

There’s also a sandboxing feature planned, so 3rd-party applications can be executed in a sanbox by default, so the system and user data remains safe even if users install stuff not checked by the distributor. The difficult thing about this will be picking a sandbox-solution. The Listaller implementation will be easy, everything is already there. And of course, the project needs bug-fixing work! ^^

We also require people to create IPK packages. The process of doing that is extremely easy. Yes, we inherited parts of Autopackage, but creating a Listaller package is definitely easier than creating an Autopackage. 🙂

All of these features will be implemented with the next releases of Listaller, if we follow the roadmap.

We need help!

If you are a developer and like developing in Vala and C, we need you! If you don’t know Vala, no problem, it’s really easy to learn and I can help. You could also create packages or translate the project.

Also, for distribution packagers: Some people wanted to include Listaller packages in their distribution’s repos, but I said “please, not now”, because Listaller was in an experimental state at that time and I didn’t want to disappoint users with alpha-software. Now, we need Listaller packaged in distributions, so if you still want to do that, do it now! 🙂

Try Listaller?

You can download Listaller from the Download Page. You will at leas need PackageKit>=0.7.2, but I recommend using PackageKit 0.7.4, which might be released today. You also need GLib>=2.26, SQLite and Redland to build the software. After installing it, Listaller will start working as part of PackageKit and you will be able to install Listaller packages.

…next steps

I plan to release new Listaller versions every month now, probably in sync with the PackageKit release cycle. Also, testing should be increased and missing features will be implemented, while maintaining the package format backward-compatible, if possible. (Please note that I still will break it if there are good reasons for it!)

In the (very) long term, I could even imagine making the Open Build Service create LI packages, but that’s far future 😉

So, expect some more news on this project later 🙂