> 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.

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:

    fn hex_primary(input: &mut &str) -> Result<u8> {
        take_while(2, |c: char|  c.is_ascii_hexdigit())
            .try_map(|input| u8::from_str_radix(input, 16))
            .parse_next(input)
    }

> 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.

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?