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
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
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
@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,
@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:
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
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
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`)
I don't know if people see init.lua as something to be used or avoided, but I
have played with it on and off over the past few years. When playing with
macros I generally do anything even mildly complicated in lua, and I ended up
with a basic debugging framework and a set of utility functions.