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.
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.
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.
I think that is why you have something like the official Arch repo -which are categorized further as well- and the AUR. You would expect an AUR package to not work, but the packages that are officially available in the normal repos should be reliable.
That’s why I think maybe NixOS should have a separate way to contribute niche packages that a few people actually use it but one could grab packages from. Because waiting for packages to be approved in nixpkgs or having to manually import one from other’s repos is a little bit tedious IMHO.
Some potential issues:
Hi,
I sort of had the same idea. But more like:
Sounds like a good feature to add to GitHub - jonringer/nix-template: Make creating nix expressions easy
There are lots of technical issues that’d need to be solved and almost all of them are impossible to solve 100% but they can be solved to a sufficient degree such that it works for some percentage of AUR packages.
The problem is that the ABS is conceptually different from Nix’ stdenv. It often assumes you can simply download random things from the internet during a build which simply isn’t possible with Nix (for good reason).
It’d take a lot of work to build up package name mapping tables and many packages simply won’t work because of the aforementioned packaging system differences.
Better put all that hard work into packaging things natively and maintaining them.
Repology.org has a huge database that could be used to map project names between nixpkgs and the AUR.
Good point!
There are lots of other technical hurdles to overcome and impossibilities to accept though, so I think the point that the effort would be better put into “just” packaging things natively still stands.