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

▲

nabla9 10 hours ago | parent [-]

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

	▲	mqus 10 hours ago \| parent \| next [-]
		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.
	▲	imtringued 9 hours ago \| parent \| prev [-]
		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.