Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2018-11-27 Thread Jason Tibbitts
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

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2018-11-27 Thread Panu Matilainen
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

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2018-11-27 Thread Panu Matilainen
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

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-10-27 Thread Jeff Johnson
@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,

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-10-27 Thread Igor Gnatenko
@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:

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-10-27 Thread Jason Tibbitts
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

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-09-25 Thread Jeff Johnson
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

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-09-24 Thread ニール・ゴンパ
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`)

[Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

2017-09-07 Thread Jason Tibbitts
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.