NomCup
This is a Rust library that parses PKGBUILD
files used by pacman the package manager.
There are three main sources of inspiration for the name:
- namcap — a Pacman package analyzer
- nOm — an awesome Rust library to create parsers
- rUst — language this library is written in
Now it's a hungry cup, waiting to eat all the tokens from your PKGBUILD
.
Goals
- Parse a PKGBUILD file into a reasonable Rust structure
- Understand and render variables
- Generate back a file with original formatting
Secondary goals
- Generate a file with opinionated formatting
- Provide warnings and recommendations
Notes
This library is created to provide a proper way to work with PKGBUILD in the pacops
tool.
One of the key pacops
features is updating a package.
Let's take microsoft-edge-dev-bin as an example.
It has source
array with https://packages.microsoft.com/repos/edge/pool/main/m/microsoft-edge-dev/${_pkgname}_${pkgver}-1_amd64.deb
in it.
pacops
should be able to understand that it's a remote source (not a file in a package directory), that it's a .deb
file.
If it's a .deb
it means it's probably a repository, so it should try to get a list of files in the repo.
From file name, it should be able to tell their versions and compare to the current one.
If a newer version is found, pacops
should update version and hash field in PKGBUILD.
We don't need to have this functionality baked into this lib, but we have to provide a reasonable interface to make it easy in pacops
.
Ideas
The following should be discussed before implementing
Storing token tree next to a Rusty struct
It's a good thing to provide developers with an easy to use interface, but there is a goal with something about "original formatting". It means it not enough to just parse PKGBUILD and then build it back in a general way. I'm not sure how well it's going to work but in a process of parsing, we are building a tree of tokens that also represent formatting. It might be possible to build a file back from this tree modifying only relevant pieces.
Metadata
The parsed result is going to look something like .SRCINFO
meaning that all the values are already rendered:
https://packages.microsoft.com/repos/edge/pool/main/m/microsoft-edge-dev/${_pkgname}_${pkgver}-1_amd64.deb
is going to look like this
https://packages.microsoft.com/repos/edge/pool/main/m/microsoft-edge-dev/microsoft-edge-dev_89.0.760.0-1_amd64.deb
While it makes a link usable as a link it's now harder to understand where the version is inside it.
Maybe it's going to be easier to go through the repo when we know how the link was built.
For this, we can have several ways to represent source in our API: rendered, template with links to PKGBUILD
variables.
Or something like that.
It's possible to look for occurrences of version and pkgname in versions but there can be some extra logic (-git
or anything else).
Links
- libalpm - Arch Linux Package Management (ALPM) library
- Pacman homepage