LAPP — Linux Application Package
A modern application packaging format for Linux.
LAPP is designed to make Linux applications easier to distribute and install by packaging an application and its required files into a single standardized package.
Download one package. Install one application. Run it.
LAPP is an application packaging format and package management system for Linux.
The goal is to provide a simple, predictable way to distribute applications independently of traditional Linux distribution package managers.
A LAPP application is distributed as a single:
.lapp
package.
For example:
FirefoxESR-140.13.0-x86_64.lapp
The package contains the application, its resources, metadata, and the information required by the LAPP package manager.
LAPP aims to provide:
- Simple application distribution
- Portable Linux applications
- Distribution-independent application packages
- A predictable filesystem layout
- Secure package validation
- Human-readable application metadata
- Desktop integration
- Easy installation and removal
- Multiple CPU architecture support
- A straightforward command-line interface
- Future graphical installation tools
A LAPP package is an archive containing a standardized application directory.
A typical application may look like:
MyApplication/
├── manifest
├── bin/
│ └── myapplication
├── lib/
│ └── myapplication/
└── share/
├── applications/
│ └── myapplication.desktop
└── icons/
└── myapplication.png
The exact contents of an application depend on the application itself.
The important requirement is that every LAPP application contains a valid:
manifest
Every LAPP application contains a file named:
manifest
The manifest uses the native LAPP key-value format.
A minimal LAPP manifest looks like:
format=1
name=MyLibraryApp
version=0.1.0
architecture=x86_64
entrypoint=bin/myapp
The manifest is intentionally simple and does not use JSON, YAML, TOML, XML, or another external serialization format.
| Field | Description |
|---|---|
format |
LAPP manifest format version |
name |
Application name |
version |
Application version |
architecture |
Target CPU architecture |
entrypoint |
Executable used to start the application |
format=1
name=FirefoxESR
version=140.13.0
architecture=x86_64
entrypoint=bin/firefox
The format field allows the LAPP manifest specification to evolve while maintaining compatibility with previous package formats.
The lapp command-line program is used to manage LAPP packages.
lapp info MyApplication.lappExample:
==> Opening LAPP package...
Name: MyLibraryApp
Version: 0.1.0
Architecture: x86_64
Entrypoint: bin/myapp
lapp install MyApplication.lapplapp run MyApplicationlapp remove MyApplicationLAPP validates packages before installing them.
Validation may include:
- Manifest validation
- Package structure validation
- Archive integrity
- Archive path validation
- Archive file type validation
- Symbolic-link validation
- Architecture validation
- Entrypoint validation
- Package security checks
For example:
==> Validating package...
==> Checking archive security...
Archive paths: OK
==> Checking archive file types...
Symlink: OK
==> Package validation successful.
Security is an important part of the LAPP design.
A package should never be blindly extracted into arbitrary locations on the filesystem.
LAPP applications are intended to be installed independently from the traditional system package database.
A user installation may look conceptually like:
~/.local/
└── lapp/
└── MyApplication/
├── manifest
├── bin/
├── lib/
└── share/
This allows applications to be installed without requiring every application to modify the system filesystem.
The exact installation paths are implementation details of the LAPP package manager and may evolve as the specification develops.
The entrypoint field in the manifest specifies the executable that launches the application.
For example:
entrypoint=bin/myapp
with:
bin/
└── myapp
When LAPP launches the application, it resolves the entrypoint relative to the installed application.
The entrypoint must point to a valid executable within the LAPP application.
LAPP packages may contain symbolic links when required by an application.
For example:
lib/
└── firefox-esr/
├── firefox-esr
└── firefox-bin -> firefox-esr
The package validator checks symbolic links as part of archive security validation.
LAPP must ensure that symbolic links cannot escape the package or cause files outside the permitted installation area to be overwritten.
LAPP is designed to support normal Linux desktop applications.
Applications may provide:
.desktopfiles- Application icons
- MIME associations
- Application launchers
- Desktop metadata
For example:
share/
├── applications/
│ └── myapplication.desktop
└── icons/
└── myapplication.png
The goal is for an installed LAPP application to behave like a normal Linux desktop application.
LAPP supports architecture-specific packages.
Examples include:
x86_64
aarch64
armv7
riscv64
The target architecture is declared in the manifest:
architecture=x86_64
The LAPP package manager can use this information to determine whether a package is compatible with the current system.
Linux already has many package formats and distribution-specific package managers.
LAPP is not intended to replace traditional system package managers.
Traditional package managers are excellent at managing system components such as:
- System libraries
- Kernel components
- Services
- System utilities
- Distribution infrastructure
LAPP focuses primarily on applications.
Examples include:
- Desktop applications
- Third-party applications
- Portable applications
- Applications distributed independently of a Linux distribution
- Applications that need a predictable installation environment
A traditional distribution package might look like:
myapp.deb
or:
myapp.rpm
and is generally built specifically around the package management system of a particular Linux distribution.
A LAPP package instead focuses on the application itself:
myapp.lapp
The intention is that the same LAPP application can be distributed across compatible Linux systems without requiring the application developer to maintain a separate package for every distribution.
A typical LAPP package name follows this pattern:
Name-Version-Architecture.lapp
For example:
MyLibraryApp-0.1.0-x86_64.lapp
or:
FirefoxESR-140.13.0-x86_64.lapp
Package naming is primarily intended to make packages easy to identify when downloading, storing, and distributing them.
The LAPP ecosystem is divided into separate projects.
The core LAPP project provides the package format and package management infrastructure.
Individual applications can maintain their own LAPP packaging projects.
For example:
LAPP
├── lapp
│ └── LAPP package manager
│
├── lapp-firefox
│ └── Firefox LAPP archive
│
└── application repositories
└── Individual LAPP applications
This separation allows the package manager, application packages, and package archives to evolve independently.
LAPP projects may use different repositories for different purposes.
Contains the actual LAPP application and its packaging/build configuration.
myapplication/
├── manifest
├── bin/
├── lib/
├── share/
└── build scripts
Contains released .lapp packages.
lapp-myapplication/
├── MyApplication-1.0.0-x86_64.lapp
├── MyApplication-1.1.0-x86_64.lapp
└── README.md
This allows application development and binary package archives to remain separate.
Security is a core part of the LAPP design.
The package manager should validate package contents before installation and prevent malicious archive structures from escaping the intended application installation directory.
Areas of consideration include:
- Path traversal
- Absolute paths
- Symbolic links
- Hard links
- Unexpected filesystem objects
- Executable entrypoints
- Archive corruption
- Architecture mismatches
- Manifest manipulation
LAPP is being designed with the assumption that packages may come from untrusted sources.
The manifest contains a format version:
format=1
This allows the LAPP format to evolve.
Future versions may introduce additional manifest fields or package capabilities while retaining the ability to identify the format used by an existing package.
The format version describes the LAPP package format, not the application version.
For example:
format=1
name=MyApplication
version=2.4.1
architecture=x86_64
entrypoint=bin/myapplication
Here:
format=1
describes the LAPP format, while:
version=2.4.1
describes the application.
LAPP is currently under active development.
The package format, package manager, installation model, security validation, dependency handling, and desktop integration are evolving.
The project is experimental and should not yet be considered a replacement for established Linux package managers.
Potential future development includes:
- Stable LAPP format specification
- Package signing
- Package checksums
- Repository support
- Dependency management
- Application updates
- Rollbacks
- Multiple installation scopes
- Desktop integration
- Graphical installer
- Graphical application manager
- Package search
- Package repositories
- Multi-architecture repositories
- Sandboxing/isolation options
- Automated package building
- CI/CD integration
Contributions, ideas, testing, and experimentation are welcome.
Areas where contributions are particularly useful include:
- Package format design
- Package security
- Archive validation
- Dependency handling
- Application isolation
- Desktop integration
- Multi-architecture support
- Package management
- Graphical tooling
- Documentation
- Testing
LAPP is open-source software.
Individual repositories and components may have their own licenses. Refer to the LICENSE file in each repository for the applicable terms.