An attempt to create a universal package manager

[Justpav05]

Hello to the Linux forum.

I have long been tormented by the idea of trying to create a universal package manager, so that it does not turn into creating "another" single format for work, but rather uses existing formats to work with current package formats.

Therefore, I chose a more modular architecture based on the main library, which will copy files and keep track of all this in the Database, and, importantly, ostree support for rollbacks in case of unforeseen circumstances

In general, the backend would already be working with a specific type of package, which would parse the metadata and files themselves from the packages, providing a structured format for the installer.

The architecture was simple and based on the fact that all the backends and the underlying library were shared, while the CLI or any other frontend handled them specifically.

Otherwise, the work of all libraries and even the cli itself was based on the concept of a finite automaton, to simplify development and easily add new functions.

So far, my work looks like this, and most of the functionality is implemented in its raw form, but it works nevertheless.

I chose rust and zig as programming languages, since the former is good enough for tracking memory errors and race conditions, but it's hard to write shared libraries, while in zig it's harder to make mistakes in memory, and it's easier to write a shared library.

GitHub - justpav05/upac: Package manager for installing any type of package in Linux, as well as registering binary file rollbacks based on OSTree, written in Rust and Zig

Package manager for installing any type of package in Linux, as well as registering binary file rollbacks based on OSTree, written in Rust and Zig - justpav05/upac

github.com

 

[KGIII]

We prefer it if you use the site as a member before you use our site to advertise your wares.

In this case, I'll allow it - once. Do not make other threads about your project. Keep your future project comments in this thread.

Thanks for understanding that we are not your advertising platform.

 

[dos2unix]

I can appreciate this, and honestly hope it works well.

There is always the old gzip/tar files. (Does slackware still use this?)

dnf, yum, apt, pacman, yast, portage, etc....

I would think the hardest part isn't the package format itself, but rather managing all the dependencies
that go with a certain application. This is what snaps, flatpak, and appImages try to do, by including them
all withing the application container.

In rpms and deb files, (the only two formats I've really ever dissected). There is something called a spec
file, and it lists all the other package dependencies that a specific application needs.

 

[Justpav05]

We prefer it if you use the site as a member before you use our site to advertise your wares.

In this case, I'll allow it - once. Do not make other threads about your project. Keep your future project comments in this thread.

Thanks for understanding that we are not your advertising platform.

Yes, of course, I understand. It’s just that, for the time being, I really wanted to contribute something new to the Linux community and ask certain developers to help me resolve some accumulated issues.

I apologize, I won't do that again.

 

[Justpav05]

I can appreciate this, and honestly hope it works well.

There is always the old gzip/tar files. (Does slackware still use this?)

dnf, yum, apt, pacman, yast, portage, etc....

I would think the hardest part isn't the package format itself, but rather managing all the dependencies
that go with a certain application. This is what snaps, flatpak, and appImages try to do, by including them
all withing the application container.

In rpms and deb files, (the only two formats I've really ever dissected). There is something called a spec
file, and it lists all the other package dependencies that a specific application needs.

Yes, that will be the main problem; however, for now, I am simply trying to develop the database and properly design the installer's workflow so that everything functions correctly.

 

[craigevil]

bauh was a decent all-in-one package manager, but it hasn't been updated since 2024.

GitHub - vinifmor/bauh: Graphical user interface for managing your Linux applications. Supports AppImage, Debian and Arch packages (including AUR), Flatpak, Snap and native Web applications

Graphical user interface for managing your Linux applications. Supports AppImage, Debian and Arch packages (including AUR), Flatpak, Snap and native Web applications - vinifmor/bauh

github.com

It currently supports the following formats: AppImage, Debian and Arch Linux packages (including AUR), Flatpak, Snap and Web applications.

 

[CaffeineAddict]

I would think the hardest part isn't the package format itself, but rather managing all the dependencies
that go with a certain application. This is what snaps, flatpak, and appImages try to do

I envision the best universal package manager, on that beats existing *.deb, *.rpm etc. formats as well and flatpaks, appimages etc.

It's as 'simple' as a database, e.g. a repo, of make files or project files that build desired packages from source.
This is nothing new though, an example is vcpkg, MS's package manager that builds libs for C/C++

Linux eco-system would benefit from such a thing that's geared toward OS packages.

 

[Justpav05]

I envision the best universal package manager, on that beats existing *.deb, *.rpm etc. formats as well and flatpaks, appimages etc.

It's as 'simple' as a database, e.g. a repo, of make files or project files that build desired packages from source.
This is nothing new though, an example is vcpkg, MS's package manager that builds libs for C/C++

Linux eco-system would benefit from such a thing that's geared toward OS packages.

Yes, but I was really just aiming to implement support for installing all existing formats, as well as support for an immutable /usr with the ability to add files to packages. That would be cool, because it would eliminate the problem of partial package updates in Linux and, furthermore, allow it to become the most stable system.

 

[KGIII]

I apologize, I won't do that again.

Just keep it confined to one thread, and you're generally okay with staff. Don't start turning it into a bunch of threads. Don't create a new thread every time you update. That sort of stuff.

 

[Trml]

Yes, but I was really just aiming to implement support for installing all existing formats, as well as support for an immutable /usr with the ability to add files to packages.

Your project reminds me of the VanillaOS's apx package manager (https://github.com/Vanilla-OS/apx). If you don't know it, perhaps it gives ideas. It's different by using containers. Is that not an approach that, while more resource intensive, make system stability more readily achievable?

It might be too early, but have you thought about handling package signatures? I like the way AUR handles them, pretty transparent and user-focused.

 

[Justpav05]

Your project reminds me of the VanillaOS's apx package manager (https://github.com/Vanilla-OS/apx). If you don't know it, perhaps it gives ideas. It's different by using containers. Is that not an approach that, while more resource intensive, make system stability more readily achievable?

It might be too early, but have you thought about handling package signatures? I like the way AUR handles them, pretty transparent and user-focused.

Unfortunately, I haven't thought about signatures yet, because the database itself hasn't been implemented well enough to have a reason to continue working.

Thank you for your tips, I hope they will help me. But I'd rather have someone to help me with the development.

 

[Justpav05]

Just keep it confined to one thread, and you're generally okay with staff. Don't start turning it into a bunch of threads. Don't create a new thread every time you update. That sort of stuff.

Yes, of course. I would like to discuss all the information related to him here, so that I don't get lost myself later

 

[Trml]

Unfortunately, I haven't thought about signatures yet, because the database itself hasn't been implemented well enough to have a reason to continue working.

Yes, it sure has to wait, I was mostly curious. In contrast to the AUR, I find the standard Debian way rather in-transparent, since .deb repo packages don't contain a signature (only the repo database does). It appears to be a more complicated logic to mimic in a way coherent with other sources, which either embed or ship an individual package signature.

But I'd rather have someone to help me with the development.

Once you progress with first collaborators, perhaps think how to employ the git platform features. Some projects use tags (e.g. "feature", "help wanted", "doc", "bug") as planning output to structure and prioritise next steps.

 

[Justpav05]

Yes, it sure has to wait, I was mostly curious. In contrast to the AUR, I find the standard Debian way rather in-transparent, since .deb repo packages don't contain a signature (only the repo database does). It appears to be a more complicated logic to mimic in a way coherent with other sources, which either embed or ship an individual package signature.

Once you progress with first collaborators, perhaps think how to employ the git platform features. Some projects use tags (e.g. "feature", "help wanted", "doc", "bug") as planning output to structure and prioritise next steps.

Unfortunately, I am working on such an ambitious project alone, so it is unlikely that I should expect any significant assistance from anyone.

 

[Trml]

Why unlikely? As @CaffeineAddict said, it's complex but very interesting for the ecosystem.

After all there are a lot of users who may be happy with their Linux platform, but have this or that application that they'd prefer to receive from another channel. For example, while I have a base system with rolling Arch, I do use a couple packages that are primarily maintained by Debian devs. It works with an AUR package, but if they were more complex - dependency management may run into issues easily. The other way around (Debian base but choose and pick occasional packages form a more current repo) should be even more frequent.

You appear to have had an impressive start with tackling it already. Give it some time.

 

[Justpav05]

Why unlikely? As @CaffeineAddict said, it's complex but very interesting for the ecosystem.

After all there are a lot of users who may be happy with their Linux platform, but have this or that application that they'd prefer to receive from another channel. For example, while I have a base system with rolling Arch, I do use a couple packages that are primarily maintained by Debian devs. It works with an AUR package, but if they were more complex - dependency management may run into issues easily. The other way around (Debian base but choose and pick occasional packages form a more current repo) should be even more frequent.

You appear to have had an impressive start with tackling it already. Give it some time.

Yes, but I need to raise a little money, as I am currently working with a free AI tool that isn't particularly helpful with the actual work. Right now, I am trying to address the bugs in my project—specifically, attempting to fix them by partially refactoring the core library. As soon as I finish that, I will start working on the dependencies, and afterward, I will try to add a remote repository.

 

[Justpav05]

I wanted to say that the project is not abandoned, and work is underway to improve it. The main library has been redone and the cli has been redone in the process, comments have also appeared in many files, and the backends are gradually being polished with minor changes. The change also affected the configuration, and a bit of the folder layout