You might have heard it: Listaller 0.5.1 was released some days ago. Listaller 0.5.1 is a complete rewrite in Vala. But the Vala rewrite is not the only thing which makes this release “special”: This is the first Listaller release after 10 months. And this is the first release of the “reoriented” Listaller. During the 0.4.x series, we focused on making software-management with Listaller as easy as possible. The AppStream project renders lots of this Listaller functionality obsolete, so we now focus on the second aspect of Listaller: Cross-distro software installations. (Of course the management part is still important, but most management tasks will now be handled by AppStream tools) While all previous Listaller releases were designed to give package creators as much control as possible the “new Listaller” will take full control over the setup process.
It took some time to convince me this is a good idea, but it definitely is. Because packagers have less control, the chances of damaging the system with a Listaller package are marginal. You simply have less possibilities to do wrong packages. And because Listaller is not designed to install system components, the loss of flexibility is no problem in most cases.
The new setup-process also allows distributors to change Listaller’s internal setup policy as they like, which will make all further 3rd-party software installations which are made using Listaller, compliant with their own distro-policy. And last but not least we can now easily reject “bad” packages by using the new livalidator which checks for packaging mistakes.
Okay, enough about the new Listaller and generic Listaller info, I think if you’re reading this blog you already have a brief idea what it is good for. 🙂
The Listaller 0.5.1 release only provides a shared library and some command-line tools at time – boooring! A lot of people don’t know what do do with this lib, so I was asked to write a small preview of what Listaller can do at time. (And all the stuff it cannot) This is a very good idea IMO, because there are no Listaller packages available at time for testing. So, let’s get started:First of all: If you wonder about the GNOME screenshots, because you know me as KDE user: I still use KDE, but the GNOME people can do cool stuff too and I’m testing the GNOME-Shell at time 😉
Listaller provides some command-line tools at time, which can be used for building new IPK packages:
autocompile is an automagic application-compiler. If you know Debian, you might know dh_auto_build too, which does the same as autocompile. If you don’t know Debian’s package helper scripts: Appcompile will detect the software’s build-system and execute the required commands to compile the application (e.g. ./configure && make) It will also add some generic compile-flags.
depscan scans the dependencies of an application. At time it can only detect dependencies from binaries using ldd but later it might be extended to detect e.g. Python dependencies too or find out deps from package source.
runapp is a helper program to run applications installed with Listaller. You will find more information about it if you continue reading 😛
libuild assembles IPK files from software sources. It needs a set of “definition files” in a subdirectory to be able to create the package. I’ll publish instructions how to build IPK packages later, if the IPK format became more mature.
A cli to install/remove applications using Listaller is still missing, it might be added later.
Okay, enough about command-line tools. As Listaller is a shared library only, you need a frontend to see it in action. I show Listaller-GNOME here. There is a KDE frontend too, which is not ready yet. (First I need to rewrite the Qt4 bindings)
So, we want to install an IPK package now, the cool Osmos game by Hemisphere Games. Osmos is a perfect test case for Listaller, as it has less dependencies and is one of these typical applications which are not in distribution-specific repositories. Remember, Listaller wants to provide a direct path from upstream to users – for open source publishers as well as for companies producing proprietary software. And – a very important reason – I really like the Osmos game, you should definitely try it 🙂
So, we run
I’m really sorry for this ugly setup-wizard and I’m sure user interface designers would beat me for that 😀 But I’m no expert in GTK+ programming and designing, if you can do better please contact me ^^ (In fact, I started with GTK+ a few months ago)
As you can see, the first page shows some basic security information. The “Should be safe” message is shown because Listaller checked the GPG signature of this package which is my own. Because I trust myself, this package is safe to install 😛 Of course, some more information about the package security should be displayed here, which is already on my TODO list.
Because every application installed by Listaller is run in a sandbox by default, the risk to damage something or to install malware should be marginal anyway.
On this page the user can also set a checkbox “Install for all users” – This will make Listaller install the application system-wide. Otherwise it is installed into users $HOME directory. All the system-wide shared-installation stuff is done by Listaller’s PackageKit extension, more about this later. 🙂Of course some more information is shown in this wizard, like the application description or – as in the screenshot above – the software license.
Finally the installation is started. If Listaller wants to install the application system-wide, a PolicyKit dialog will show up, asking for authorization.Listaller will resolve all dependencies now. At time Listaller only supports the native distribution repositories as dependency sources, but it will also support ZeroInstall feeds as an alternative later.
When the installation has finished, Osmos Demo shows up in the “applications menu”, just like any other native application does too.There is something special about this application launcher: Instead of starting Osmos directly, it will execute Listaller’s runapp tool with the application name as parameter.
This is necessary for various reasons: First of all runapp sets some environment variables which make Osmos find it’s dependencies. But runapp is also responsible for sandboxing the Osmos application, so it can run with minimal permissions. Sandbox support is currently at work, the plan is to use the Arkose Sandbox. The runapp tool can also prevent applications from being executed, e.g. the system-administrator can easily add a rule to block an application like Skype etc. (of course one can easily execute the application anyway, but he has been warned by runapp not to do that…) The last two features still need implementation. (And I’m not sure if the application-blocking makes sense, so this feature is delayed)So, Osmos Demo is working perfectly well with runapp 🙂
If we want to get rid of the newly installed Osmos application, we can easily fire up limanager-gtk, an application responsible for removing Listaller applications. If Osmos was installed as shared application, there is a better way to remove it: PackageKit.
If PackageKit is compiled with a patch for Listaller, all PK frontends are able to remove and update Listaller applications. So Listaller apps are integrated perfectly well with the rest of the system. Of course Listaller also integrates with components of the AppStream project, which allow tools like the Ubuntu Software Center to handle Listaller apps too (but this code is at an early state at time)As you can see, the newly installed Osmos Demo Listaller application shows up in GNOME-PackageKit and can be removed too.
This also works great with Apper on KDE and every other PackageKit frontend.
Okay, this was the short overview of what Listaller can do at time. There is still a lot of work to do, e.g. the dependency solver needs some improvements and the PackageKit integration is incomplete at time. Also, the user interfaces are in a very bad shape at time ^^
If you want to help, contact me on the Listaller mailing list. And don’t forget: There will be more frequent releases of Listaller now 🙂
Update: I nearly forgot one important thing: