<p></p>
<p>Changed title to more generic.</p>
<p>As mentioned in the related PR, I think the suggested approach of parsing a single section of the spec fundamentally differently from others is neither the easiest or the best solution, both from user and implementation perspective. The mixed macros vs pseudo macros vs shell script mess of spec is difficult to follow as it is, we should be making things easier not harder.</p>
<p>An external file that is parsed for inclusion after <code>%install</code> execution  can be created from the spec or  external scripts/tooling, be it <code>%spec -f <foo></code> or whatever in the spec syntax itself (something modeled after the familiar <code>%files -f foo</code>, see below).  As that file is parsed with the same macro expansion as the spec itself, this doesn't prevent deep macro magic in any way. And as that file doesn't even exist initially there can be no confusion about when and where things are expanded etc.</p>
<p>We can have a new scriptlet that <em>executes</em> after %install for creating that file, but it needs to be <em>parsed</em> along the rest of the spec. That could of course be equally achieved from end of <code>%install</code> but conceptual separation from that would probably be better (just like we should have separate slots for unpacking and configuring the sources)</p>
<p>As for the inclusion syntax, we could add a kind of pseudo section named <code>%spec</code> which if present, marks the beginning of a spec, just like <code>%files</code> does for file section (optionally accompanied with <code>%end</code>). This  might well serve some other parsing-related purposes as well, but for starters it gives us a place to add that <code>-f <foo></code> for the subspec to be parsed after <code>%install</code>. At the beginning of a spec it would place it quite far from the place where said file gets created so there might well be better alternatives (such as allowing multiple <code>%spec -f</code> constructs throughout, or something) this is just to outline a design that fits with the rest of rpm / spec.</p>
<p>That sort of thing makes it possible to add new sub-packages on the fly from any old tooling, but additionally we could look at a native Lua API that could be used for adding sub-packages, running from a special Lua-specific slotf after <code>%install</code> - <em>not</em> talking about macros here.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/1222#issuecomment-728882322">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ADLPZUZR3SFXAU36YJN2RR3SQJRAVANCNFSM4NBRY7XQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/ADLPZU2GD57PLNYKOC3WP4LSQJRAVA5CNFSM4NBRY7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFNY5ZEQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/rpm-software-management/rpm/issues/1222#issuecomment-728882322",
"url": "https://github.com/rpm-software-management/rpm/issues/1222#issuecomment-728882322",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>