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

nim-nim notifications at github.com
Tue Jul 7 07:48:56 UTC 2020


> %postbuild is misleading and dangerous. You need a dynamic starting point for every section that succeeds %post, 

More generally, the problem you are attempting to solve, is not the lack or not of a new rpm section, and the shredding or not of the existing spec file. Those are all fuzzy workarounds, that will succeed, to an extent, and frustrate you, to a greater extent.

The problem you are attempting to solve, is that you want to modify the shell bits rpm will execute later in the build, based on the build results so far. And that you absolutely can not do that from the shell, because the shell can not self-modify the script it is running, and rpm design loses environment between two shell invocations, so you can not easily tell the next shell session what you have computed so far.

So a good generic solution, would not be to shred the spec file into ever smaller files, or to add new sections every six months, as you realise you missed a modification point packager need.

A good solution would be to add *explicit* (not implicit, and not tied to whole sections, as they exist today) start and end markers to shell sessions (subshell like).

So something like
```rpm
%{sh:
}
```

And everything in %{sh:}  is evaluated when the execution plan gets to the `%{sh:}` part and no earlier, and plopped to a new shell script, given to bash to execute 

And between an the end of %{sh:} and the next %{sh:} you stop the shell execution and compute, in a different execution environment than the shell itself (my preference being obviously lua) the things you want to execute in the next shell sessions. And shell execution restarts with a new shell script the next time the parser encounters a %{sh:} tag (or when the lua code feeds it an 
```rpm
rpm.expand([[
%{sh:
something
}]])
```

For backwards compatibility reasons you probably do not want to authorise %{sh:} sections that overlap existing section boundaries. And (also for backwards compatibility reasons) you probably want to consider that a section, that executes a separated shell script today, has an implicit %{sh:}  spanning the whole section, if you find that the packager did not mark where to begin executing and where to pause when you get to this section.

Of course being able to compute the next execution bits is not really useful if you can not inject those bits in the next part of the spec. So your must have either prepared entry points in the next %sh/%endsh runs, where the new execution instructions will be injected (that’s basically what %auto_prep/%auto_build/etc are in my specs) or call an explicit new shell session with  
```
rpm.expand([[
%{sh:
something
}]])
```

once you have computed the something.





-- 
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-654665701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200707/54a43828/attachment.html>


More information about the Rpm-maint mailing list