On 03/03/2016 10:55 AM, Florian Weimer wrote: > * Stephen Gallagher: > >> On 03/03/2016 10:22 AM, Florian Weimer wrote: >>> On 03/03/2016 04:00 PM, Stephen Gallagher wrote: >>> >>>> So what I am looking for is someone who is fluent in LUA to help me convert >>>> these scripts over so that they can run entirely under the built-in LUA >>>> interpreter of RPM and eliminate this problem. >>> >>> I know that the language is spelled “Lua”, not “LUA”. Not sure if >>> that's enough qualification. >>> >>> The fundamental question is whether you want to preserve this script as >>> a Lua script, for running outside of RPM. If not, we can >>> constant-propagate the command line flags into the script and simplify >>> it somewhat. >>> >> >> The ideal case is for it to be usable by the end-user to change the >> Edition (or, more commonly, assign one if it's non-product at the >> moment). That said, I'm open to treating that as a nice-to-have and >> fixing just the install/upgrade cases right now. > > It's possible to maintain two scripts if necessary. It is what we are > doing for the /etc/localtime update in Red Hat Enterprise Linux 6. > tzdata has a Lua implementation as a %post scriptlet, and glibc > provides a C implementation for use by system administrators. > > I asked because a realistic getopt would be fairly involved to > reimplement in pure Lua. (There must be countless implementations of > that already, but I'm not sure if we want to add another dependency, > or lift an implementation from some wiki page.) The rest of the script > seems quite doable. I'll take a stab at it later today if no one else > shows up. > I have no problems maintaining both scripts; I can just install the current bash script as-is and just keep them in sync if we make changes. If we do this right, changes should be extremely rare. Thank you for your help. >>> Note that the script would have to run under the RPM Lua interpreter, >>> the plain Lua interpreter does not provide some required functionality >>> (such as posix.files function). And you cannot run the script from a >>> file system path, you have to put it directly into the spec file. >>> >> >> So all the content has to be inline, or we can create a common >> script/function and call it multiple times? > > We can inline the file at build time using Lua scripting, I think. > OK
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
