[Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)

nim-nim notifications at github.com
Sun May 10 11:20:40 UTC 2020


> So I guess this is waiting for me to put my thoughts here…

A lot of those things are already handled Fedora-side in our fonts and go packaging macros.

1. you define a pivot `%{fooX}` variable, with X a suffixed index à la %{SOURCEX}. If it is present in the spec file, that means you need to generate the foo set of packages with foo rules (you can mix subpackages of different types in a spec file, ie fonts + go in golang-x-image, you can have multiple subpackage of the same type in the spec file, and a single control variable may generate multiple kinds of subpackages, for example for Go we want to generate go source module packages, gopath source packages, and eventually dynlib packages. %{gomodX} means generating the three above subpackages for each %{gomodX} line in the spec)

2. for each %{fooX} pivot variable, you define a set of optional sub-variables that allow controlling the generation. For example %{gomodsummaryX} will contain the summary of the Go module subpackage associated with %{gomodX}, and if not set by the packager will be autocomputed to 'The %{gomodX} Go source package'

You end up with a *huge* list of subvariables, that are only set in special cases, so the average spec is kept small and maintainable.

Thus, we have a %{fontlicenseX} that allow setting the license of a font subpackage (with a fallback to %{license}). Font file bundled distributed with other stuff are usually subject to their own licensing. We have a  %{foolicensesX} that sets the licensing files associated with a subpackage. We have a  %{foodocsX} that sets the documentation files associated with a subpackage

3. And lastly, we have %{fooheaderX} that lets the packager inject manual header elements in generated subpackages, typically manual Provides/Obsoletes, because that’s downstream stuff that can not be guessed from upstream metadata.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/329#issuecomment-626312340
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200510/8d38e44a/attachment.html>


More information about the Rpm-maint mailing list