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

[Eli Schwartz]

On 3/8/20 9:45 PM, Allan McRae wrote:
> 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.

Yep -- like I mentioned before, this should be opt-in via something
explicitly in the PKGBUILD, libprovides is a good example of how to do that.

> 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.

I kind of also need to extend this for my WIP / languishing attempts at
https://git.archlinux.org/users/eschwartz/pacman.git/log/?h=autoversioned-dependencies,
so there's definitely some interesting stuff you could do with this.
That being said, changes to the metadata generation have a tendency to
become thing that also need lint_pkgbuild changes, so I'm not 100%
convinced thirdparty extensions can be done here *safely*.

(I suppose we could just say "eh, if you modify it, it's your fault if
it breaks".)

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200308/d39ce86f/attachment.sig>