<p><a href="https://github.com/jasontibbitts" class="user-mention">@jasontibbitts</a>: apologies if you have interpreted "serious" as a criticism of your personal efforts<br>
That wan not my intent.</p>
<p>Meanwhile, your suggested patch -- the only positive suggestion of what you wish -- is little more than force loading a number of modules based on globbed names, regardless of usefulness (to rpm embedding of lua), total ignoring the support within the lua language to load modules (either scripts or C level bindings) through LPATH/CPATH, including envvar overrides. Otherwise, your patch would be a vital first step to changing how rpm+lua functions: meanwhile prior art exist, using what is implemented in lua-5.x since 2003. Just ... why reinvent round wheels imperfectly?!?</p>
<p>(aside)<br>
I claimed no "serious" attempt to use rpm+lua since 2003. That is in fact not true: there is an entire *nix distribution that chose to use rpm+lua embedding in order to create a distribution, which "worked" but alas, not rpm4.org code. Meanwhile, I will quote the person who used rpm+lua to do that distribution</p>
<ul>
<li>"If rpm had embedded perl instead of lua, I would not have used rpm+lua".<br>
I'm sure you can find the distribution that I refer to.</li>
</ul>
<p>Now for other interpretations of "serious"</p>
<ul>
<li>there have been no attempts to patch init.lua until your RFE (that I am aware of). You are welcome to examine the last ~15y of rpm releases to ascertain the objective truth of my claim.</li>
<li>using patterns to force load modules -- while well intended -- ignores changes to support LPATH/CPATH requires(foo) loading that are now part of lua (for at least 4y now, albeit lua has abandoned at least one module loading scheme since 2003).</li>
<li>force loading modules (as in your patch) forces another lua layer to "require" whatever modules rpm deems useful. There is no well defined way to track module existence within rpm dependencies, particularly when (as likely) lua is being used in %pretrans scripts. Specifically: what is rpm to do when, say, some module is unavailable in an <em>empty</em> tree after chroot(2) has been performed? Returning an error is not a satisfying answer imho.</li>
</ul>
<p>A "serious" implementation for rpm+lua embedding with init.lua has (at a minimum, imho) MUST attempt to deal with chroot(2) path prefixes on <em>empty</em> chroot's using (if up to me) mount -bind calls to map trees from the host into the hosted chroot tree. YMMV.</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/321#issuecomment-340133804">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb800rNzuBokNaCM3LEc74k8uj_petXks5swpMIgaJpZM4PQdz7">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb800WcJSvI8tZrcuZDeW1FjSCuAho2ks5swpMIgaJpZM4PQdz7.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/321#issuecomment-340133804"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #321: @jasontibbitts: apologies if you have interpreted \"serious\" as a criticism of your personal efforts\r\nThat wan not my intent.\r\n\r\nMeanwhile, your suggested patch -- the only positive suggestion of what you wish -- is little more than force loading a number of modules based on globbed names, regardless of usefulness (to rpm embedding of lua), total ignoring the support within the lua language to load modules (either scripts or C level bindings) through LPATH/CPATH, including envvar overrides. Otherwise, your patch would be a vital first step to changing how rpm+lua functions: meanwhile prior art exist, using what is implemented in lua-5.x since 2003. Just ... why reinvent round wheels imperfectly?!?\r\n\r\n(aside)\r\nI claimed no \"serious\" attempt to use rpm+lua since 2003. That is in fact not true: there is an entire *nix distribution that chose to use rpm+lua embedding in order to create a distribution, which \"worked\" but alas, not rpm4.org code. Meanwhile, I will quote the person who used rpm+lua to do that distribution\r\n* \"If rpm had embedded perl instead of lua, I would not have used rpm+lua\".\r\nI'm sure you can find the distribution that I refer to.\r\n\r\nNow for other interpretations of \"serious\"\r\n* there have been no attempts to patch init.lua until your RFE (that I am aware of). You are welcome to examine the last ~15y of rpm releases to ascertain the objective truth of my claim.\r\n* using patterns to force load modules -- while well intended -- ignores changes to support LPATH/CPATH requires(foo) loading that are now part of lua (for at least 4y now, albeit lua has abandoned at least one module loading scheme since 2003).\r\n* force loading modules (as in your patch) forces another lua layer to \"require\" whatever modules rpm deems useful. There is no well defined way to track module existence within rpm dependencies, particularly when (as likely) lua is being used in %pretrans scripts. Specifically: what is rpm to do when, say, some module is unavailable in an *empty* tree after chroot(2) has been performed? Returning an error is not a satisfying answer imho.\r\n\r\nA \"serious\" implementation for rpm+lua embedding with init.lua has (at a minimum, imho) MUST attempt to deal with chroot(2) path prefixes on *empty* chroot's using (if up to me) mount -bind calls to map trees from the host into the hosted chroot tree. YMMV.\r\n\r\n\r\n"}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/321#issuecomment-340133804"}}}</script>