>>>>> "FW" == Florian Weimer <fweimer@xxxxxxxxxx> writes: FW> It's often necessary to use Lua for scriptlets which run reliably FW> because RPM lacks delayed script execution. I guess it depends on how delayed you want them. The ordering is certainly well defined but it's all a bit esoteric. But sure, Lua is there and it works. Unfortunately it lacks usability because it really needs a standard library and more state needs to be visible in the Lua symbol table. In any case, I did try to play with some basic library for interfacing with RPM stuff from within Lua scripts (debug output, manipulating macro values, etc.) which is actually all kind of tricky but the mechanism provided for you to add functions into the Lua symbol table is kind of primitive and needs at least some consensus before something starts using it. FW> In the RPM land, we can only use statically linked binaries or Lua FW> in such cases. The cases where you _have_ to do that are really quite limited. FW> I have extensively used install-time scripting with Lua for packages FW> in the toolchain space (glibc and tzdata in particular; not all of FW> this is in Fedora). So, sure, glibc is tough since immediately after that package is installed you have no scripting. FW> However, this use is controversial because some FW> RPM lookalikes do not implement Lua scriptlets. For Fedora that certainly isn't a concern. FW> Furthermore, changes in this area (such as replacing Lua with other FW> mechanisms such as shell scripts) are difficult to test properly FW> because differences in RPM or the repository contents could cause FW> dependency loops be broken at different points. Well, yes, low level distribution work is hard and the environment as you are doing an initial OS install is, at least in the early part of the process, extremely limited. But I don't recall a problem which didn't have a reasonable solution. (Perhaps that depends on how you define "reasonable" though. Some would argue that using Lua at all isn't reasonable.) - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
