An Experimental Package Manager For Operating Systems: LPM

Today, I'm excited to introduce the project I've been working on lately called LPM (Lod Package Manager). Designed to be simple, fast, and adaptable which aims to change the way we manage software packages on UNIX like operating systems.

Contributions are absolutely welcome at github.com/lodosgroup/lpm!

Overview

Because package managers are among the most critical tools for operating systems, they shold be very carefully designed from bottom to top. I aimed to make LPM super simple for both OS users and package or distribution release maintainers, while also incorporating the advantages of current modern technologies and algorithms. For package compression, LPM uses LZ4; for building packages it only requires JSON and BASH experience. LPM's dependency tree includes only LZ4 and SQLite3, which are dynamically linked at runtime to avoid increasing the binary size of LPM. These libraries were created under the LodOS Group (the group which LPM is also classified), indicating that they are carefully designed and minimized for specific use with LPM.

Package install and delete demonstration in docker

I haven't released any stable version yet, therefore I push for as many beneficial improvements as possible, even if they offer small marginal benefits in terms of security, performance, or binary size. Following this extremist ideology, LPM appears much quicker than any existing package managers today, even in its current state (experimental, not highly optimized, etc).

Dynamic Module Support

LPM supports dynamic modules that are only loaded when invoked, such as lpm --module builder --build .. This means you can write a module for LPM in any language that can build a dynamic/shared library compatible with the C ABI. For example, LPM's builder module is written in Go. Any implementation not directly related to core package management will be implemented as an optional LPM extension to avoid bloating LPM directly.

To understand how it's done, you can find examples in various programming languages at github.com/lodosgroup/lpm-modules/tree/main/.example-module. With this approach, anything can be implemented/supported on LPM without bloating the core package management layer. For instance, I can support installing RPM and DEB packages(for sure this is challenging, but it's possible and supported from the design of LPM) by writing modules for them (e.g., lpm --module dpkg install lzip.deb).

No Custom Scripting Language

If you have average experience with BASH and JSON, you already know how to release/build packages with LPM. I don't want to complicate things by requiring people to learn and use custom scripting language for maintaining system packages. Features in LPM will be presented on the CLI, and there is no need to learn or write code for installing/maintaining system packages.

Written in Rust

Rust is a good choice for writing a system level project for a few key reasons. Rust's focus on preventing common programming mistakes ensures that the package manager is reliable and less prone to errors that can cause system issues. The language's emphasis on security, facilitated by its ownership system, helps create a more robust and secure package manager. Furthermore, Rust's performance characteristics make it well-suited for tasks like managing software installations and updates, ensuring that the package manager operates efficiently even at a large scale. Additionally, we won't need to rewrite it in Rust in the future (you did smile accept it).

It's Just Fast as ****

Even though xbps is a very fast package manager (likely the fastest one, assuming LPM is not ready for real usage and no one knows it yet), let's compare the performance in simple operations.

For what is worth in this example LPM install one extra package called gc.

Host System:

LPM Results when installing from remote repository(network overhead is involved):

XBPS Results when installing from remote repository(network overhead is involved):

LPM when installing with cache(from FS where network overhead is not involved):

XBPS when installing with cache(from FS where network overhead is not involved):

You may don't care about the package manager performance for your OS, but CI runners do! Specially the paid ones..

Architecture Agnostic Repository [in progress]

LPM and its builder will support both prebuilt and source packages simultaneously. Currently, we only have the linux-amd64-default repository. Once this feature is implemented, we will introduce another repository named source. This repository will contain packages as sources, giving you the option to install your package by compiling it. This approach allows you to compile programs for directly your system with specific optimization build flags/args.

For example, if you are an ARM user and the package you are looking for isn't in the ARM repository (which is a common occurrence with other package manager repositories), you can still install it with LPM, as long as the project codebase itself supports your CPU architecture. This means that both ARM and AMD64 users can use the same source repository and install the same package with the same command. This method of installation provides you with the ability to change build flags and arguments, giving you complete control over the compilation process.

Workspaces (Isolation and Efficient Disk Usage) [upcoming]

With workspaces, you will be able to create a workspace, let's say "development-space", and install working tools/programs there. When needed, everything contained in that space can be removed with a single LPM command. Most of the time, you don't use the majority of your installed packages on your system, and they all consume disk space. With workspaces, when you don't activate them, they will be kept in a compressed format. So, when you have multiple workspaces and they are not activated, they will be stored in a compressed format, taking up much less disk space than it would if you installed everything on the system directly(like you do right now). This feature is not yet implemented and is planned to be introduced with the beta release.

Snapshots [upcoming]

LPM uses SQLite3 to store package, repository, and internal information. Similar to the lock files used by language package managers, LPM will provide you with a dump of your system's status from the database. Wit that, you will be able to use this dump to restore all your packages and workspaces on another system with single LPM command. This feature is not yet implemented and is planned to be introduced with the beta release.

Rootless Mode [upcoming]

Not everything absolutely needs to be installed with root permissions; this is a relatively basic/simple yet highly beneficial task. This feature is not yet implemented and is planned to be introduced with the beta release (yeah this is copy-pasted three times, sorry for that).

Q: Why did I do something like this when I could have a good life?

I am crazy.

Q: What's coming up next?

After the beta release, I plan to develop a proper pid0 (init process handler) that aligns with the same philosophy as LPM and is compatible with systemd unit configurations (only the core parts). Together with LPM, I hope to make a Linux Distribution called LodOS. I am definitely not going to keep these projects to myself until the end. I simply want to contribute something valuable to the community. It's not personal my friend; it's strictly free and open source!