[pacman-dev] [RFC] Make PKGBUILD attributes configurable

[Dustin Falgout]

> 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 at archlinux.org> on behalf of Eli Schwartz <eschwartz93 at gmail.com>
Sent: Saturday, April 22, 2017 9:00 PM
To: pacman-dev at 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