This looks both cool and over-engineered. For some reason it gives me a bit of flashback to Java6 days of EE Bean servers though with crates upon crates.
Plus take the winnow library parser example. I’m not sure it’s gonna be easier to follow or debug than a standard recursive descent parser:
> The ALPM project arose from the need for more clearly specifying the interfaces, as well as providing bindings and tools in a memory-safe programming language.
Whose need?
As an admin and a user I kindly ask: why? what for?
`pacman` which has been and is working fine for over two decades on multiple architectures is two packages - and that includes mirror finder.
This project seems like a CS exercise: funded by a grant, designed by committee, producing a lot of complex artifacts (already over a dozen packages)... and it's unclear if the lot of that can even install a single package.
Arch package management isn't just pacman, but also makepkg, namcap, dbscripts, devtools (pkgctl and others). As end-user/sysadmin you may not even have heard about them but distro is built atop them.
As a sysadmin I'm very familiar with `makepkg`, its config file and the fact that sooner or later one will need both `clang` and `gcc`, because they're equivalent only in theory ;-)
But as I maintain only a library of pre-build(-once) software, rather than being an actual package maintainer - surely there is the whole other side that I normally do not see, much less touch.
Having said that, I'm all for better tooling - it's just that the project doesn't even hint, much less describe, the actual benefits for the people who will (sooner or later? have to?) use it.
And, unfortunately, I've been doing this for long enough to approach _any_ increase in complexity with at least anxiety, if not outright sadness (at "you could have spent that time/money on more _useful_ work", usually).
They created a specification for the PKGBUILD format and a library to parse PKGBUILD files.
If you wanted to use PKGBUILD files to build Ubuntu or Debian packages, you could in principle build your own makepkg implementation for building Ubuntu packages.
You could also build an SBOM tool that takes a PKGBUILD and produces the SBOM using the PKGBUILD metadata of all the transitive dependencies.
They are also working on something that could be summarised as "IDE" features. Validation and linting of PKGBUILD files not unlike what a language server/IDE does (e.g. rust analyzer or IntelliJ).
EDIT:
There is also a library for programmatic creation of PKGBUILD files, so build systems could integrate with it to automatically produce Arch Linux packages. This could make building your own Arch Linux packages even easier than it already is.
It's an implementation detail, you're saying it like they're completely free form. Not really, they have a very specific structure that every package adheres to.
Parsing them currently requires evaluating them as shell scripts. Should be obvious how bad of an idea it is, especially in the context of the AUR (which is why it requires you to push a dumbed down metadata file called SRCINFO along with PKGBUILD — which is then used to show package info in the web UI you're probably familiar with).
Being able to safely parse PKGBUILDs without running them would certainly be an improvement.
Arch Linux doesn't fork upstream projects and usually only does minimal changes/patches to a package. This means package maintainers spend the vast majority of their time packaging.
When you think about it, a Linux distribution should upstream useful changes to the original project and have the changes be available through configuration. But if that is the case then the vast majority of the code lives outside the Linux distribution. The package manager including the server backend might be the largest code base of Arch Linux and perhaps even the only one that has a meaningful size to begin with.
> The GnuPG upstream has denounced the IETF-driven OpenPGP standardization process and has subsequently been removed from other major package management software such as apt and rpm over the last three years. Compatibility with other OpenPGP implementations is no longer guaranteed...
What?? First time I'm hearing of this schism. I wish the FOSS community had less disagreements all over the place.
This is a waste of Sovereign Tech Fund money. That money is supposed to fund the digital sovereignty of Germany and Europe. Yet, they put €500,000 into this. It seems open-source developers have their own way of performing their own version of corporate capture.
Considering Arch is one of the big upstream distros and, alongside Debian and NixOS, one of the big community-run ones, standardizing and improving its foundations is certainly not a waste. Moreover some results are usable beyond Arch, e.g. VOA (for storage and retrieval of signature verifiers). Choosing Rust though does impose some portability limitations. (Even if makes sense to not want to use C in 2020s.)
This is not improving anything. Overly complex and starting from scratch. They should have picked dome existing package manager instead and contributed to it. Yet another package manager is not justifiable anymore. Always starting new package manager from scratch is the bane of oss it seems.
But this _is_ improving the pacman ecosystem? Afaict its aiming to be a drop-in replacement of existing tools, but with proper libraries so systems like buildbtw can be built around it.
ALPM is not a makepkg/pacman implementation, it is a set of libraries to make it easier to build makepkg/pacman implementations.
It's kind of like the OCI image specification, but for the "Dockerfile" portion of Arch Linux package management rather than the binaries. Competitors like Debian don't even have something that is equivalent to PKGBUILD or Dockerfile. You're expected to know how to setup and build a project on your own and then have packaging be a separate step that happens at the end. They are heavily reliant on institutional knowledge of package maintainers and are impenetrable to outsiders that are unwilling to spend days on building their first package.
I'd never heard of this until right now, but Jesus Christ, Hacker News, this is an awful lot of griping for a project that appears to be completely additive with zero impact to end users or administrators of Arch Linux. pacman is still around and still uses libalpm, not this. The FAQ and mission seem pretty clear that this exists, at least for now, solely for the benefit of packagers and maintainers. They decided making this as a modular set of specifications and libraries would be best to allow arbitrary downstreams to make use as they see fit, but the only current project using this, as far as I can tell, is a project that automates updates for package builds and possibly the Python bindings are either used by the AUR website or soon will be to extract and display package metadata.
I get the cynicism and griping when it's the latest in LLM slop, capitalist surveillance state, and corporate churn for the sake of churn, but where on Earth is the harm in this? They wanted some low-level utilities for reading, writing, and manipulating package files and metadata, for whatever reason found the existing libalpm lacking, so made this. It doesn't appear that any end-user Arch packages use it or depend upon it, you'll not need to install this or the larger Rust toolchain unless you independently decide you want to, but there's a bunch of complaining anyway.
As a user, is anything going to change? I don't want to need to know about whatever this is. Everything already works fine. Are you planning on breaking it?
No, Archlinux was repeatedly behind with package updates. This even went as far as lagging behind Ubuntu in at least one instance, causing inconvenience and frustration for users which then either had to use other more up-to-date sources for dependencies or package the newer version of dependencies under a different installroot themselves.
This problem is caused by a staff shortage or the average necessary maintanance effort for repo packages. At least one of those 2 causes has to be solved.
It does it's job. I've been using it on the desktop for decades now with never needing to care about anything like that. If it ain't broke, don't fix it...
There's a staff shortage and instead of catching up on packaging tasks the project is building the 19th, what 20th package management system that Linux has now, instead of using battle tested systems like .deb and .rpm?
That is why projects like Arch ... Nixos ... etc ... all eventually become "niche".
Nah, you can keep both. Arch and Alpine are the only two distributions where I bother to build proper packages for everything because their package managers make it so easy to do the right thing.
It might be the 20th package manager in existence, which would be a problem, if Debian maintainers did not release a 20th way to build .debs just a year or two ago, mostly (but not really) deprecating the previous 19 ways. No thanks.
Its not "building a new package management system", "alpm" is literally the foundation of the pacman ecosystem. They are improving this so they _can_ catch up on packaging tasks.
I'm the same as the sibling commenter, I don't want to have another deb or rpm distro. The AUR wouldn't exist without pacman&makepkg.
This looks both cool and over-engineered. For some reason it gives me a bit of flashback to Java6 days of EE Bean servers though with crates upon crates.
Plus take the winnow library parser example. I’m not sure it’s gonna be easier to follow or debug than a standard recursive descent parser:
> The ALPM project arose from the need for more clearly specifying the interfaces, as well as providing bindings and tools in a memory-safe programming language.
Whose need?
As an admin and a user I kindly ask: why? what for?
`pacman` which has been and is working fine for over two decades on multiple architectures is two packages - and that includes mirror finder.
This project seems like a CS exercise: funded by a grant, designed by committee, producing a lot of complex artifacts (already over a dozen packages)... and it's unclear if the lot of that can even install a single package.
Arch package management isn't just pacman, but also makepkg, namcap, dbscripts, devtools (pkgctl and others). As end-user/sysadmin you may not even have heard about them but distro is built atop them.
As a sysadmin I'm very familiar with `makepkg`, its config file and the fact that sooner or later one will need both `clang` and `gcc`, because they're equivalent only in theory ;-)
But as I maintain only a library of pre-build(-once) software, rather than being an actual package maintainer - surely there is the whole other side that I normally do not see, much less touch.
Having said that, I'm all for better tooling - it's just that the project doesn't even hint, much less describe, the actual benefits for the people who will (sooner or later? have to?) use it.
And, unfortunately, I've been doing this for long enough to approach _any_ increase in complexity with at least anxiety, if not outright sadness (at "you could have spent that time/money on more _useful_ work", usually).
They created a specification for the PKGBUILD format and a library to parse PKGBUILD files.
If you wanted to use PKGBUILD files to build Ubuntu or Debian packages, you could in principle build your own makepkg implementation for building Ubuntu packages.
You could also build an SBOM tool that takes a PKGBUILD and produces the SBOM using the PKGBUILD metadata of all the transitive dependencies.
They are also working on something that could be summarised as "IDE" features. Validation and linting of PKGBUILD files not unlike what a language server/IDE does (e.g. rust analyzer or IntelliJ).
EDIT:
There is also a library for programmatic creation of PKGBUILD files, so build systems could integrate with it to automatically produce Arch Linux packages. This could make building your own Arch Linux packages even easier than it already is.
Aren’t PKGBUILDs just shell scripts?
It's an implementation detail, you're saying it like they're completely free form. Not really, they have a very specific structure that every package adheres to.
Parsing them currently requires evaluating them as shell scripts. Should be obvious how bad of an idea it is, especially in the context of the AUR (which is why it requires you to push a dumbed down metadata file called SRCINFO along with PKGBUILD — which is then used to show package info in the web UI you're probably familiar with).
Being able to safely parse PKGBUILDs without running them would certainly be an improvement.
Arch Linux doesn't fork upstream projects and usually only does minimal changes/patches to a package. This means package maintainers spend the vast majority of their time packaging.
When you think about it, a Linux distribution should upstream useful changes to the original project and have the changes be available through configuration. But if that is the case then the vast majority of the code lives outside the Linux distribution. The package manager including the server backend might be the largest code base of Arch Linux and perhaps even the only one that has a meaningful size to begin with.
> The GnuPG upstream has denounced the IETF-driven OpenPGP standardization process and has subsequently been removed from other major package management software such as apt and rpm over the last three years. Compatibility with other OpenPGP implementations is no longer guaranteed...
What?? First time I'm hearing of this schism. I wish the FOSS community had less disagreements all over the place.
This is a waste of Sovereign Tech Fund money. That money is supposed to fund the digital sovereignty of Germany and Europe. Yet, they put €500,000 into this. It seems open-source developers have their own way of performing their own version of corporate capture.
Considering Arch is one of the big upstream distros and, alongside Debian and NixOS, one of the big community-run ones, standardizing and improving its foundations is certainly not a waste. Moreover some results are usable beyond Arch, e.g. VOA (for storage and retrieval of signature verifiers). Choosing Rust though does impose some portability limitations. (Even if makes sense to not want to use C in 2020s.)
This is not improving anything. Overly complex and starting from scratch. They should have picked dome existing package manager instead and contributed to it. Yet another package manager is not justifiable anymore. Always starting new package manager from scratch is the bane of oss it seems.
https://en.wikipedia.org/wiki/List_of_software_package_manag...
But this _is_ improving the pacman ecosystem? Afaict its aiming to be a drop-in replacement of existing tools, but with proper libraries so systems like buildbtw can be built around it.
This is not another package manager.
https://alpm.archlinux.page/faq.html
ALPM is not a makepkg/pacman implementation, it is a set of libraries to make it easier to build makepkg/pacman implementations.
It's kind of like the OCI image specification, but for the "Dockerfile" portion of Arch Linux package management rather than the binaries. Competitors like Debian don't even have something that is equivalent to PKGBUILD or Dockerfile. You're expected to know how to setup and build a project on your own and then have packaging be a separate step that happens at the end. They are heavily reliant on institutional knowledge of package maintainers and are impenetrable to outsiders that are unwilling to spend days on building their first package.
I'd never heard of this until right now, but Jesus Christ, Hacker News, this is an awful lot of griping for a project that appears to be completely additive with zero impact to end users or administrators of Arch Linux. pacman is still around and still uses libalpm, not this. The FAQ and mission seem pretty clear that this exists, at least for now, solely for the benefit of packagers and maintainers. They decided making this as a modular set of specifications and libraries would be best to allow arbitrary downstreams to make use as they see fit, but the only current project using this, as far as I can tell, is a project that automates updates for package builds and possibly the Python bindings are either used by the AUR website or soon will be to extract and display package metadata.
I get the cynicism and griping when it's the latest in LLM slop, capitalist surveillance state, and corporate churn for the sake of churn, but where on Earth is the harm in this? They wanted some low-level utilities for reading, writing, and manipulating package files and metadata, for whatever reason found the existing libalpm lacking, so made this. It doesn't appear that any end-user Arch packages use it or depend upon it, you'll not need to install this or the larger Rust toolchain unless you independently decide you want to, but there's a bunch of complaining anyway.
As a user, is anything going to change? I don't want to need to know about whatever this is. Everything already works fine. Are you planning on breaking it?
> Everything already works fine.
No, Archlinux was repeatedly behind with package updates. This even went as far as lagging behind Ubuntu in at least one instance, causing inconvenience and frustration for users which then either had to use other more up-to-date sources for dependencies or package the newer version of dependencies under a different installroot themselves.
This problem is caused by a staff shortage or the average necessary maintanance effort for repo packages. At least one of those 2 causes has to be solved.
What packages are you talking about?
It does it's job. I've been using it on the desktop for decades now with never needing to care about anything like that. If it ain't broke, don't fix it...
> What packages are you talking about?
Maybe Python: https://old.reddit.com/r/archlinux/comments/1azkxnn/whats_ho...
The fact that you personally haven't encountered an issue, doesn't mean that no issue existed.
Okay, I'm saying don't break it.
Use Rocky
No thanks. It works. Don't break it. Thanks.
There's a staff shortage and instead of catching up on packaging tasks the project is building the 19th, what 20th package management system that Linux has now, instead of using battle tested systems like .deb and .rpm?
That is why projects like Arch ... Nixos ... etc ... all eventually become "niche".
Nah, you can keep both. Arch and Alpine are the only two distributions where I bother to build proper packages for everything because their package managers make it so easy to do the right thing.
It might be the 20th package manager in existence, which would be a problem, if Debian maintainers did not release a 20th way to build .debs just a year or two ago, mostly (but not really) deprecating the previous 19 ways. No thanks.
Its not "building a new package management system", "alpm" is literally the foundation of the pacman ecosystem. They are improving this so they _can_ catch up on packaging tasks.
I'm the same as the sibling commenter, I don't want to have another deb or rpm distro. The AUR wouldn't exist without pacman&makepkg.
is Allan McRae still in the team? If so, he would break it. But if not I assume that everything will work seamlessly, bar unfortunate situation.