Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
Indeed, thanks. -- 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-442258681___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
Okay so actually a drop-in directory for Lua bits was always implemented in rpm itself (/usr/lib/rpm/lua/), only the last time it was functional is was so long ago that practically nobody was using Lua for anything back then. It has just recently been fixed in upstream by commit dd6c65044c41922193f520ace668e2c5e55f1004 and since then, and included in the stable 4.14.2.1 release as well. Closing, we don't need a special init.lua for this now. -- 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-442046853___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
Closed #321. -- 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#event-1989478376___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
@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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
@jasontibbitts just FYI, 4.14 is out so master is open for breaking (kinda joke) ;) -- 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-340077422___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
My understanding is that the later definition simply overrides the former. But I would expect that conventions for namespacing would work to prevent accidental conflicts and if you can't redefine then you would just use functions in a namespace. I don't see why that would be mandatory, though of course actually documenting the behavior would be a great idea. And, well, I certainly thought I was making a serious attempt to use it. And in any case why does it matter that "nobody" has tried to use it? RPM is esoteric and there are only a few people who even get down to this level. I don't know how early init.lua is parsed but if it's after rpmrc files are parsed then it would certainly be possible to look in private directories. Should be easy to determine that in any case. And sure, I'd love to see better Lua support. I'd really like to see more RPM state exposed in the Lua symbol table, but I'm not yet sure how to do alter things to make that happen. -- 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-340070799___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
Everyone wants modules: rpm needs to support both LPATH and CPATH, in a private rpm tree as well as "standard" system paths. init.lua "support" has been in place since 2003 and no-one (that I know of) has made any serious attempt to use. -- 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-332071923___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)
I think this is an excellent idea, but I'm not sure of the semantics of what happens when something is redefined in another lua file. For example, if `/usr/lib/rpm/lua.d/foo.lua` ships function `do_foo` and `/usr/lib/rpm//lua.d/bar.lua` (in Fedora's case, the `RPMCANONVENDOR` is `redhat`) ships a function `do_foo` and it's initialized later, what happens? In regular RPM macros, the former is clobbered by the latter. If there's a different behavior, things get really tricky very quickly. -- 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-331710715___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
