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