Frequently Asked Questions

Table Of Contents

Will Listaller replace DEB/RPM?

Listaller is no replacement for the package management system of your current distribution. It only extends the package manager and provides an easy and secure way to install applications or new versions of apps which are not in the distribution's repositories.

Listaller packages were never designed to replace DEB or RPM, and due to their limitations it won't be possible anyway, so don't worry.

Has Listaller something to do with Opkg?

No. The Ipkg/Opkg project only uses the same file extension as Listaller for their installation files (IPK). Opkg-IPK files are based on the Debian-package structure, Listaller-IPK packages are based on XML files and Tar/XZ archives. If using the same file extension for both systems is too much confusing, it is possible to change it. (But at time, this wouldn't be useful.) [For information: Ipkg was a lightweight package management system. The system is currently not maintained, a new version, released under the name "Opkg" is used for OpenMoko phones]

Why write Listaller, you can use PPAs or 1-Click-Install!

PPAs are Ubuntu-specific, 1-Click-Install is openSUSE only. Listaller aims to support all important Linux distributions. Also, there are some security issues PPAs have and Listaller doesn't have. For the same reasons, PackageKit doesn't support 1-Click-Install. The issues with PPAs are:

Listaller allows sandboxing of 3rd-party applications and installs them in a way which doesn't interfere with the existing operating system and potential OS upgrades.

Quoting Sebastian Heinlein, Allowing to easily add third party repositories and install third party software without a certification infrastructure is like opening the gates to hell. Most user just don't have got the technical understanding to handle this well.

OMG, Listaller will break my native package manager (apt, yum, zypper, ...)!!!

Hey, this is not a question! ;-)
Regarding the problem you might think could happen: No, Listaller won't break anything. The project was designed to not interfere with existing package managers, so you can still safely upgrade your distribution and work with your package manager database as you want to. No package blocks/pins, no automatic installations or removals.

However, Listaller will watch parts of the native package database, if some applications installed by Listaller rely on components installed via native packages. Then, Listaller will only show hints if you try to run the application and offer re-installing the missing stuff, but it won't perform any action regarding native packages by itself.

What is an "application"?

Listaller can only install applications and should not be used to install frameworks etc. To define an application, we use the following criteria of what it should have:

Of course you might also install a non-GUI program with Listaller, but as orientation for developing the software, we use the definition above. To define a "framework" or system-tool is a bit harder. As orientation: Everything which ships a new system-bus DBus service, new PolicyKit rules or needs very strong system-integration (like an init-system, a new kernel, ...) will fall in this category and won't be supported by Listaller. Big GUI frameworks like GTK+ or Qt are also frameworks and should be provided by distributors.

What is Hughsie's law?

A joke that started on IRC late one night in '07. Put formally it is: Authentication or license prompts can only be done before the transaction has started, and messages or notices about the transaction can only be shown after the transaction has completed.

This is a PackageKit rule (see the PackageKit pages for details), but Listaller follows it strictly. To make it concrete: Listaller does not allow asking any questions except license questions before running a setup. First-run configuration should be done when the application is first run, global system configuration should be done by the system's administrator. For general set-up stuff, Listaller automatics should pick the right defaults, so there is really no need to bother users with additional questions.

Do you have user-profiles?

Yes. We use the same profiles PackageKit uses, you can read them here. For user-interaction, we develop for the needs of user in this profile (as orientation). For developers, we try to provide a flexible solution with good defaults. Where developer and user interests conflict, we will decide for users. (But this rarely happens, usually users and developers have the same interest) - If you can provide good use-cases for a new feature you propose, we will certainly add it.