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
signature.asc
Description: OpenPGP digital signature
