Idea: pacman2nix and aur2nix tools

I wonder if it is possible to make an aur2nix that can convert Arch Linux AUR packages to Nix packages, or pacman2nix to convert official Arch packages to Nix packages.

There’s lots of packages in the AUR! It’s be neat if we could specify something like aur.foo to simply install them.

1 Like

Sounds like a nice idea, but I do not think its easy.

There are at least 2 important files as well on the AUR, as well as in the ABS.

  • PKGBUILD is a collection of variables and functions, which are sourced into a shell session for the build (loosely spoken). Especially does it contain a bunch of functions which do unpacking, patching, compiling, testing, stripping, installation. They do expect all builddepends (not sure about the name right now) to be in PATH as well as all depends.
  • .SRCINFO contains a semi-easily parsable format that specifies some metadata again (extracted from PKGBUILD earlier). Its basiccally just there that the server of the package database does not need to evaluate the bash script and needs to be up to date with the PKGBUILD when comitting. It might be easier to parse this from nix directly, though the only relation between checksums and input files is still only the order of appearance.

Not even to speak about the fact, that there are always hidden dependencies. Any package in the ABS can assume that all packages from base (a package group) are installed. It can assume this during build and runtime. Packages from the AUR can even assume base and base-devel to be available at all times. I’m not sure if this is easily representable in a adjusted aurenv or absenv based on stdenv.

Not even to speak about the fact that the functions for the phases in a PKGBUILD make completely different assumptions about the environment they run in.

Last but not least, I have to admit, that there are a lot of packages on the AUR that don’t specifiy build dependencies correctly and therefore fail in a sandbox, but suceed on non-sandbox that has the tools installed because of other reasons. Those packages on the AUR can stay below the radar for quite a long time, as there are only a handfull of people currently that do sandboxed builds at all, because they either use only makepkg or their AUR helper uses it, and doesn’t have an option for something else. Only a few people actually use (a wrapped) makechrootpkg for building in a sandbox. I’m one of these and reporting issues as I discover them, but until they get fixed it takes time (if they get fixed at all).

Also remember, that dependencies don’t map 1:1 to some nix packages, so you had to recurse the dependencies and aur2nix/abs2nix them as well. Not sure yet how to treat optional dependencies…

AUR packages built from VCS might be another problem, as their build output does depend on the VCS’ HEAD/TIP at build time and do not have a proper checksum.

3 Likes

I see why the idea might sound compelling, but I doubt it is strategically worthwhile.

Ignoring technical details for a moment, the biggest problem I see is the need to manually fill the gaps a much larger community did not manage to. If it would really mean importing a repository of work wholesale, it would not matter how complicated a one-off solution needs to be, as we can see with importing from Hackage and PyPI.

The problem is even more pronounced in this case of a general package management effort, which has much more overlap (and therefore potential for friction) with nix concerns than any language-specific ecosystem. And having something that only sort of works is an enormous maintenance and support burden. It - probably more importantly - would damage this project‘s reputation with regard to reliability.

3 Likes