Hacker News Reader

Comment by drbig | Hacker News Reader

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

View on HN

Arch package management isn't just pacman, but also makepkg, namcap, dbscripts, devtools (pkgctl and others). As end-user/sysadmin you may not even have heard about them but distro is built atop them.

As a sysadmin I'm very familiar with `makepkg`, its config file and the fact that sooner or later one will need both `clang` and `gcc`, because they're equivalent only in theory ;-)

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

They created a specification for the PKGBUILD format and a library to parse PKGBUILD files.

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.

Aren’t PKGBUILDs just shell scripts?

It's an implementation detail, you're saying it like they're completely free form. Not really, they have a very specific structure that every package adheres to.

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.

Well, I have seen PKGBUILDs with arbitrary logic defining the metadata:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=webor...

Which is what necessitated a separate, statically-parseable .SRCINFO.

Arch Linux doesn't fork upstream projects and usually only does minimal changes/patches to a package. This means package maintainers spend the vast majority of their time packaging.

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.

> This project can be used under the terms of the Apache-2.0 or MIT. Contributions to this project, unless noted otherwise, are automatically licensed under the terms of both of those licenses.

Thanks, German government!

Reply on news.ycombinator.com