[pacman-dev] [RFC] Make PKGBUILD attributes configurable
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. -- Dustin Falgout Email: dustin@falgout.us Github: lots0logs
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
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
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
On 04/22/2017 10:18 PM, Dustin Falgout wrote:
That sounds sensible to me. I didn't realize there was already a drop-in replacement system for makepkg. How does it work?
I don't even know what you are talking about, there is no "replacement" system and I never suggested there was. What I said was that libmakepkg is by definition extendable by simply dropping in new components, which shouldn't be news to anyone... The source contains many examples of how to extend a bash array. :) ... Also, your emails look a bit wonky -- your top-posted responses to selected quotes appear above what seems to be a *forwarded* message, which is honestly kind of confusing to read. Also, your paragraphs don't line-wrap properly, which should only happen in HTML emails since HTML emails have better ways of doing text layout. -- Eli Schwartz
I don't even know what you are talking about, there is no "replacement" system and I never suggested there was.
Okay, sure, so I added the term "replacement" to what you said because that's how I understood it when I read it (as in "drop-in replacement"). My mistake.
What I said was that libmakepkg is by definition extendable by simply dropping in new components, which shouldn't be news to anyone...
Well, TBH, it's news to me. I've never seen any documentation about what you are describing nor have I ever seen it mentioned anywhere online that I frequent. Do you have any links I can reference to know what you are talking about. I'm trying to understand how I should go about implementing what I proposed in the way that you suggested implementing such a feature should be done if it's done at all.
Also, your emails look a bit wonky -- your top-posted responses to selected quotes appear above what seems to be a *forwarded* message, which is honestly kind of confusing to read.
Sorry, there's not much I can do about it. I don't have any option to reply in the style that you are using with my client.
--
Dustin Falgout
From: pacman-dev
That sounds sensible to me. I didn't realize there was already a drop-in replacement system for makepkg. How does it work?
I don't even know what you are talking about, there is no "replacement" system and I never suggested there was. What I said was that libmakepkg is by definition extendable by simply dropping in new components, which shouldn't be news to anyone... The source contains many examples of how to extend a bash array. :) ... Also, your emails look a bit wonky -- your top-posted responses to selected quotes appear above what seems to be a *forwarded* message, which is honestly kind of confusing to read. Also, your paragraphs don't line-wrap properly, which should only happen in HTML emails since HTML emails have better ways of doing text layout. -- Eli Schwartz
On 04/22/2017 11:33 PM, Dustin Falgout wrote:
Well, TBH, it's news to me. I've never seen any documentation about what you are describing nor have I ever seen it mentioned anywhere online that I frequent. Do you have any links I can reference to know what you are talking about. I'm trying to understand how I should go about implementing what I proposed in the way that you suggested implementing such a feature should be done if it's done at all.
Well, to people hacking on the source anyway. The whole idea of libmakepkg was that you can drop in new *.sh files into the libmakepkg directory (because it is a "library") rather than editing all that tightly-woven logic in /usr/bin/makepkg Have you actually looked at what, for example, /usr/share/makepkg/tidy.sh does to allow extendable tidy options? How many different ways can I say "add code to automatically source certain types of files, and expect those files to append items to an array" without actually writing the code on your behalf?
Sorry, there's not much I can do about it. I don't have any option to reply in the style that you are using with my client.
Use a client that doesn't suck, then. -- Eli Schwartz
participants (2)
-
Dustin Falgout
-
Eli Schwartz