[pacman-dev] [PATCH] Provides generation for files (a.k.a. rpm fileattrs for makepkg)

Allan McRae allan at archlinux.org
Mon Mar 9 01:45:45 UTC 2020

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,

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.


More information about the pacman-dev mailing list