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
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
>> 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.