A Year of Work on the Arch Linux Package Management (ALPM) Project
57 points
8 hours ago
| 4 comments
| devblog.archlinux.page
| HN
drbig
21 minutes ago
[-]
> 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.

reply
kh_hk
29 minutes ago
[-]
Lots of information on the how, but didn't find much telling me why. I guess there are good reasons for ALPM. The linked website tells me "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."

This is a bit more useful but still a little short of "pacman but in rust"

reply
elcritch
3 hours ago
[-]
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)
    }
reply
guerrilla
1 hour ago
[-]
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?
reply
bionade24
1 hour ago
[-]
> 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.

reply
guerrilla
48 minutes ago
[-]
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...

reply
HendrikHensen
38 minutes ago
[-]
The fact that you personally haven't encountered an issue, doesn't mean that no issue existed.
reply
guerrilla
8 minutes ago
[-]
Okay, I'm saying don't break it.
reply
nineteen999
53 minutes ago
[-]
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".

reply
homebrewer
22 minutes ago
[-]
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.

reply
lemper
26 minutes ago
[-]
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.
reply