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.
That is why projects like Arch ... Nixos ... etc ... all eventually become "niche".
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.
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.
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...
Maybe Python: https://old.reddit.com/r/archlinux/comments/1azkxnn/whats_ho...
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.
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).
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.
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.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=webor...
Which is what necessitated a separate, statically-parseable .SRCINFO.
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.
Thanks, German government!
https://en.wikipedia.org/wiki/List_of_software_package_manag...
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 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.
What?? First time I'm hearing of this schism. I wish the FOSS community had less disagreements all over the place.
elcritch•3w ago
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: