[Rpm-maint] [rpm-software-management/rpm] Add %postbuild section / Allow dynamic sub packages (#1239)

[nim-nim]

So here is some quick and hasty feedback (I was going to write a lot more, but the laptop battery disagreed).

You need to make it possible to generate what exists in the preamble today, because otherwise the common case where a SRPM generates a single subpackage, and you want the SRPM metadata to mirror the single subpackage metadata does not work. Like you wrote that involves some preamble triaging, to separate what belongs to the build as a whole, what belongs to the SRPM header, and what belongs to subpackage headers (I have a fairly good idea of the boundaries, because my own automation needs forced me to look at the subject in the past years I don’t claim full knowledge).

%postbuild is misleading and dangerous. You need a dynamic starting point for every section that succeeds %post, otherwise packagers will just make spec goo by moving install parts in build so they are executed before the dynamic part, or conversely moving build parts to install to achieve the reverse. The current sections help structure packaging and force everyone to use a common packaging language.

You absolutely need lua evaluation to work in your new section, you absolutely need this section to see the state of global variables that were set in previous non dynamic sections, and you absolutely need the state of global variables set in this section available to the next sections. The shell is a terrible generation environment. It does not let you collect common processing code in shared libraries, and it is lacking the explicit rpm.expand lua call that makes assembling spec fragments at the lua level safe.

You do not need spec file sausage to make several generators coexist, and you do not need  spec file sausage to make generated code coexist with custom additions. The whole
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/

series show how that can be achieved, almost all the specs in there mix several generators, and almost all of them add custom processing, and the result is fine and easy to read within a single unified spec file.

Some will that the whole aim of your change is to get rid of this kind of multiplexing code (with derogatory  comments about this code), but the code works in all parts of the spec files. Adding a new multiplexing system for a new section will just layer the new system over the previous ones, since it can not replace them in the rest of the spec.

Above all do not emulate tags and especially not SourceX which is an abortion as shown by all the manners people tried to fix it over the years (SourceX; %{SOURCEX} %{S:} %sources %source_num etc). If you want to emulate something emulate %sourcelist  That was added by people that understand the good way of automating sources is to get rid of the Source Tag in the first place.

I see no future in full dynamism. There will always be some bit of info that can not be detected and requires explicit packager declaration. I see a future in blended approaches, where dynamically detected parts, complete explicit packager declarations.

Therefore, I do not believe in a future where the spec file does not start with some explicit declarations. And, while the feature is very cool, there is not much difference between "you will find Go module X in sources, and its description is Y, and its spot-approved licensing is Z" and "shall you find Go module X in sources wink wink its description is Y, and its spot-approved licensing is Z".



-- 
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/pull/1239#issuecomment-654481656
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200706/744876cf/attachment.html>