[Rpm-maint] [rpm-software-management/rpm] spec file preprocessing on rpm level (#1472)

[Michal Novotný]

> Could you explain a little bit the difference between the preproc time and the %{} expansion time? Doesn't rpm expand %{} repeatedly until no further expansion can be done?
>
> ( If there was template control flow it would make sense, because then you would have delimited blocks that you would want to process first, I think).
>
> (my point about calling bash script from lua remains)

I mean this is a good question. One reason for having a preprocessing stage is existence of source rpms. Basically both lua scriplets and shell expansions are evaluated once srpm is built and then later when rpm is built from that srpm. The thing is that contexts (i.e. what information is available to the build process) is different each time. For srpm build, there are e.g. git metadata and raw source files, whereas for rpm build, there is no longer any git metadata and sources are packed in exported (e.g. by `git archive`) tarballs. I.e. lua scriplets and shell expansions that would access the git metadata or some files that aren't tarballed into srpm will succeed first time but fail the second for the rpm build itself. Therefore if such external context is to be used, it should be done so that evaluation is done only once (when building the srpm) and later the same precomputed results are used without any additional evaluation. Koji and Copr (and perhaps other build systems) work this way that they first build and srpm and only later rpm(s) from that srpm and they also store srpms for perhaps later rebuilds. So basically, if we would be building rpms directly from raw sources (e.g. git repos), then usage of lua scriplets or shell expansions would be probably fine for tasks like renderring changelog from git history and similar. Perhaps the usefulness of srpms is what decides whether the additional preprocessing step makes sense or not but this statement might be also a bit far-fetched. E.g. Copr allows you to submit only a spec file and build from it so I could imagine a use-case where you automatically "render" (i.e. run preprocessing) that spec-file locally and then submit it to Copr as a standalone thing. It's true that in this case you wouldn't need preprocessing to be part of rpm.

There are some other differences, e.g. that you can keep variable values across separate `{{{ }}}` invocations which I think you might not be able to do with shell expansion or the lua scriplets but that's rather an implementation detail i guess.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1472#issuecomment-1023644135
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/1472/1023644135 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220127/8e639f8e/attachment.html>