General
For Developers
Limba is no replacement for the package management system of your current distribution. It is intended to be used together with the native package manager, and should integrate smoothly with it.
Limba packages were never designed to replace DEB or RPM, and due to the restrictions which apply to them, it would not be possible to build a whole distribution out of them anyway.
PPAs are Ubuntu-specific, 1-Click-Install is openSUSE only. Limba aims to support all important Linux distributions. Also, there are several security-related issues PPAs have and Limba doesn’t have. Some of the main issues with PPAs are:
Limba 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.
Officially, there is no support, since all developers test the code with higher versions. However, there is some compatibility code in place, which will allow Limba to work with lower kernel versions, if they have the OverlayFS kernel module built and installed. If OverlayFS or any other kernel feature Limba needs is missing, you will likely be able to install applications but can not run them later.
The issue of a “too old” kernel will vanish over time.
While GUI applications in graphical environments like KDE Plasma and GNOME are the primary usecase for Limba, it works well for non-GUI applications as well.
Limba even provides a few helpers to make using command-line tools installed using it much more simple. If you package a non-GUI application, just ensure
that you place a binary in bin/ (otherwise, no runtime will be created for your software).
Allowing 3rd-party software to run on your system is always a potential security risk. But Limba has a few mechanisms included which should prevent malicious software to be installed on your system. Those features include:
As always, the best security feature is awareness: Do not blindly install and run anything you find on the internet.
Limba packages should usually be provided by the upstream developer of your favourite application. It is also possible for others to compile their own repositories containing Limba packages in an “AppStore-like” manner, e.g. distributors can create Limba repositories containing software from trusted developers.
At time, there are not many Limba packages available, since Limba is still a very young project with an unstable API. but you will find some procompiled packages on Github. We will also offer a bigger repository containing a set of packages in future.
Currently, there is no official integration. Limba is still an experimental project. However, KDEs Apper can build an optional module which provides a GUI frontend for installing Limba packages. And long-term, close desktop integration is an important goal for Limba.
The systemd-team and some GNOME developers are also working on a concpt which will allow 3rd-party software installations. The ideas are outlined in Lennarts Blog. The main differences between the systemd-concept and Limba are that Limba has a much narrower scope, since it only focuses on the software deployment issue and does not aim for the large structural changes the systemd-concept implies. Limba also does not depend on Btrfs (but on OverlayFS instead).
While for the systemd-concept, every application ships its own set of libraries and binaries, Limba aims for shared dependencies between software components. This should reduce the amount of duplicate libraries and allows automatic updating of software components in order to fix security issues in shared resources. For Limba, resource-sharing in order to be able to fix security issues in individual, separated modules is an important goal. For the systemd-concept, the “one-image-per-application” idea prevents this from happening, making it more difficult to roll out security updates.
Both projects have their own advantages and disadvantages. For example, the systemd-concept ensures the developer, that his or her application will always run in the exact same environment it was tested with. Limba does not ensure that, since it allows resources to be updated independently of the main application. The potential security-issues due to outdated libraries in the systemd-concept are planned to be worked around by sandboxing each application. For Limba, sandboxing is also possible as additional safety measure.
That being said, Limba also allows to keep applications in a defined environment by locking the dependencies to a specific version (using == as version-relation).
Summarized: Limba and the systemd-concept are based on different ideas on how 3rd-party software installations should work. There are different tradeoffs involved in each idea, and objectively saying that one is better than the other is hard. Obviously, since you are reading a FAQ on Limba, we like the Limba concept more. The future will tell which of the solutions will be used more (and become a default recommendation), or if they are both equally important.
Since Limba uses some Linux-kernel features which are not (yet?) available on other kernels, it is Linux-only at time.
No. The Ipkg/Opkg project only uses the same file extension as Limba for their installation files (IPK).
Opkg-IPK files are based on the Debian-package structure, Limba-IPK packages are based on XML files and Tar/XZ archives.
Using the same file extension as Opkg has been a concern, but it is simply impossible to find a short file extension which has not been used already
by a different project. Also meaningful longer extensions (.bundle) are already taken.
To distinguish IPK files, you can always check for Limbas magic number at the beginning of the file: limba1\t\034.
(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)
Currently Limba uses some systemd functions if available, for example to perform safe atomic updates of software. In future, we will most likely use more features exposed by it, for example to put every application which is run into its own cgroup, and to make use of some nice sandboxing features. However, Limba does not have a hard dependency on systemd at time (January 2015) - it will run happily without it, and there is no reason to require it to be present at time. However, some features might not be available in future without systemd, and most people will test Limba with systemd. Additionally, Limba already has a hard dependency on other Linux kernel features, so it is really not systemd which would make it difficult to port it to other platforms.
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 Limba follows it strictly. To make it concrete: Limba does not allow asking any additional questions during installations, not even for accepting the license. 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, Limba should pick the right defaults[1], so there is really no need to bother users with additional questions.
[1]: If not, file a bug.
Software metadata needs to be written for Limba, and AppStream XML already contains all the information we need. Since the XML is a Freedesktop standard and used in a few other places, it is likely that your project already has that metadata, and it makes sense for Limba to use it.
By tieing Limba packages to AppStream component-ids, we also gain the ability to match Limba packages against software installed by the distributor. This will in future allow us to write tools which checks for duplicate software versions or software which has known security issues on your system, which can be of great help for system administrators.
Check out this short introduction: How to build a Limba package
The reason for using the second, very small lipkg/control file is that we do not want to pollute the AppStream XML file with information which is
just useful for Limba. It is nice to keep things separate which belong separate. Also, since the control-file specifies the dependencies of an IPK packages, it
is a bit nicer for humans to not use XML, since relational operators are quite common.
We also want to have a versioned IPK package specification to allow future backwards-compatible extension, and putting all that information into the AppStream metadata would have looked odd.
For packages, you can skip the signing step by passing –no-signature to lipkgen. This can be useful for development, where you quickly want to
test your package. If you ship the software to your users, you should sign the package though - otherwise, your users will likely receive a warning message on installation.
Repositories always need to be signed. Limba does not accept repositories without signature to prevent certain attack scenarios.