Regardless of the suitability of such a thing, wouldn't it make a lot more sense to try implementing it by making the attributes fully libmakepkg-ified and extending it via drop-in components for libmakepkg, rather than inventing some /etc configuration directory for what is, after all, adding new functionality rather than merely configuring the behavior?
That sounds sensible to me. I didn't realize there was already a drop-in replacement system for makepkg. How does it work?
The reason for .SRCINFO is because the PKGBUILD fields can contain any valid bash -- and pretty much always do, e.g. $pkgname-$pkgver.tar.gz in the sources.
Indeed, that's one of the things I was referring to when I said it was easier. I should have elaborated, sorry about that. -- Dustin Falgout From: pacman-dev <pacman-dev-bounces@archlinux.org> on behalf of Eli Schwartz <eschwartz93@gmail.com> Sent: Saturday, April 22, 2017 9:00 PM To: pacman-dev@archlinux.org Subject: Re: [pacman-dev] [RFC] Make PKGBUILD attributes configurable On 04/22/2017 06:53 PM, Dustin Falgout wrote:
It would be great if there was a way to customize the list of PKGBUILD attributes supported by makepkg without having to edit the installed copy of makepkg. My use-case is mainly for use with the --printsrcinfo option but I'm sure it would be useful in other areas as well. I'd like to submit a patch for it but I thought it best to see what everyone thought about the feature before spending time on it. My initial thinking is that that simple text files with one attribute per line could be placed in /etc/makepkg.d. Perhaps something along these lines:
/etc/makepkg.d/attributes.single /etc/makepkg.d/attributes.multi /etc/makepkg.d/attributes-march.single /etc/makepkg.d/attributes-march.multi
Looking forward to your comments and also any guidance on preferred implementation details.
Regardless of the suitability of such a thing, wouldn't it make a lot more sense to try implementing it by making the attributes fully libmakepkg-ified and extending it via drop-in components for libmakepkg, rather than inventing some /etc configuration directory for what is, after all, adding new functionality rather than merely configuring the behavior? Generically speaking, this is the kind of thing that motivated splitting makepkg into a library in the first place.
Sure, no problem. Currently, our build server uses some custom attributes in the PKGBUILD for additional metadata needed for things like release monitoring. I would like to start using .SRCINFO files on the server because they are easier to parse and also because it would be better convention-wise. Here's an example[1].
Convention-wise, possibly... but for static key-variable assignments like that, parsing is actually precisely as easy as .SRCINFO parsing. The reason for .SRCINFO is because the PKGBUILD fields can contain any valid bash -- and pretty much always do, e.g. $pkgname-$pkgver.tar.gz in the sources. -- Eli Schwartz