> 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 <[email protected]> on behalf of Eli Schwartz <[email protected]> Sent: Saturday, April 22, 2017 9:00 PM To: [email protected] 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
