[HELP NEEDED] LUA expert to help convert fedora-release %post scripts

[Stephen Gallagher]

As part of efforts in Fedora 24 to address certain issues with the
edition-specific fedora-release content (such as /etc/os-release, /etc/issues
and edition-specific presets), I built a moderately complex series of bash
scripts to run in %post and %posttrans to ensure that all of the right files
were symlinked in the correct places.

Unfortunately, the result here is that %post and %posttrans for fedora-release
now requires both bash and coreutils to function properly, and this introduces a
cyclical dependency. It works properly on upgrades of realistic systems (all of
which have bash and coreutils on them), but it introduces issues with mock and
minimalistic systems on installation.

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.

This is a fairly urgent issue, as it may cause blocking issues for Fedora 24
installations. So if you think you can help, please respond promptly.

I'm attaching the current fedora-release.spec and convert-to-edition bash script
for perusal.

[Florian Weimer]

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.

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.

Florian

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


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

[Florian Weimer]

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

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

Florian

[Stephen Gallagher]

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

[Panu Matilainen]

On 03/03/2016 05:55 PM, 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.
>
> >> 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. 
You can %include files into spec, and also you can pull scripts contents 
from a file with -f option to scriptlets, eg %post -f %{SOURCE5}

	- Panu -

[Florian Weimer]

On 03/03/2016 04:00 PM, Stephen Gallagher wrote:
>  I'm attaching the current fedora-release.spec and
> convert-to-edition bash script
>  for perusal. 
I'm attaching a lightly tested Lua conversion.  I'm not familiar with
all the scenarios to test, so I thought I'd post what I have quite
early.  Most of the pieces should be in place.

Florian

[Stephen Gallagher]

On 03/03/2016 02:39 PM, Florian Weimer wrote:
>  On 03/03/2016 04:00 PM, Stephen Gallagher wrote:
> > I'm attaching the current fedora-release.spec and convert-to-edition bash script
> > for perusal.
>  
>  I'm attaching a lightly tested Lua conversion.  I'm not familiar with
>  all the scenarios to test, so I thought I'd post what I have quite
>  early.  Most of the pieces should be in place.
>  
>  Florian
>   
Thanks, Florian. I cleaned up a few very minor issues and submitted pull
requests for both Rawhide and F24:

https://pagure.io/fedora-release/pull-request/29
https://pagure.io/fedora-release/pull-request/30


Thank you very much. I really appreciate you taking the time to help with this
and also your incredibly fast turnaround on it.