[Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
Jeff Johnson
notifications at github.com
Sat Oct 28 02:35:53 UTC 2017
@jasontibbitts: apologies if you have interpreted "serious" as a criticism of your personal efforts
That wan not my intent.
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?!?
(aside)
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
* "If rpm had embedded perl instead of lua, I would not have used rpm+lua".
I'm sure you can find the distribution that I refer to.
Now for other interpretations of "serious"
* 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.
* 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).
* 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.
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 *empty* chroot's using (if up to me) mount -bind calls to map trees from the host into the hosted chroot tree. YMMV.
--
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/issues/321#issuecomment-340133804
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20171028/87db4f72/attachment.html>
More information about the Rpm-maint
mailing list