On 9/3/20 6:04 am, Carson Black wrote:
The code is architected in a manner designed to make it trivial to add new provider autogenerators.
So far, there are autogenerated providers for: - pkgconfig(package) - cmake(package) - desktop files * app(desktopfilename) * can-open-mimetype(mimetype)
While these automatically generated provides can be used for packaging, this is intended more for interactive usage rather than an attempt to change how Arch packaging works.
Lets take a step back from even looking at the patch and whether it works, and focus on whether this should be a feature of makepkg/pacman at all. Firstly, I am very against makepkg performing action that are not obvious from reading a PKGBUILD. This is why our templating system pulls the code into the PKGBUILD instead of just providing a library of functions to use. That way we can read PKGBUILDs to see the build/package commands, unlike ebuilds. It is also why libprovides & libdepends require specifying the library name, and only the version is automatically added. People have previously suggested automatically adding all dependencies on libraries to depends, and have all packages provide their libraries. This was rejected. So, I can't see me accepting this idea either. However, we have started splitting makepkg into smaller parts, and allowing some parts to be extendable with drop-in files. I am using that to do checking on PKGBUILDs and packages from within makepkg (https://github.com/allanmcrae/pkglint), and people have used it to add support for more build options (e.g. the following packages in the AUR: makepkg-optimize, makepkg-tidy-ect, makepkg-tidy-pdfsizeopt, makepkg-tidy-scripts-git) One idea could be to add a method for extending a packages metadata while writing .PKGINFO. I would not accept any functions adding metadata into the pacman code base (except maybe some examples, not enabled by default), but this serves as a point for distributions to make their choices. Allan