On Tue, Sep 18, 2012 at 08:19:10PM -0300, Hisham wrote: > >> > > %files > >> > > %lua_modulesdir/* > >> > > %lua_modulesdir_noarch/* > >> > > %luarocks_dbdir/%oname > >> > > %doc LICENSE NEW README docs_from_rockstree/* > >> > > %exclude %luarocks_dbdir/manifest > >> > >> > And we don't exclude manifest, we mangle manifest's name, and later > >> > reconstruct it in postinstall hook. So _patched_ luarocks can see > >> > rocks > >> > as preinstalled. > >> > >> My approach is different: > >> * any RPM with a rock excludes manifest because obviously it is the > >> shared manifest of all rocks installed in this tree > >> * installation/update/removal of an RPM which contains a rock > >> triggers the RPM filetrigger (the unique ALTLinux technology) which > >> regenerates the manifest. No postinstall scripts required. > >> > >> Hence it > >> 1. "just works" for rocks RPMs installed into one single rock tree and > > > > And you "system" rocks invisible for luarocks, our approach make it > > visible. > > Also I believe you can hit a problem to build rocks with dependencies > > (luasec for example, without patching luasec pull own copy of loasocket > > into buildtree) > > This discussion and your different approaches are very interesting. > > Alexander, just to make sure I'm still following: the LuaRocks patch > you refer is #89, right? >
More or less related ;) My approach to packaging rely on this patch. > Thinking out loud: I notice both approaches use some project-specific > parts to implement "export to RPM" and "export to DEB". Do you guys > think it would be possible to somehow implement these features in a > generic enough manner so those could be included someday as "LuaRocks > plugins" or something like that? > My code is just few lines, using exising luarocks code as library. I think it shouldn't be exact part of LR, but LR should be more friendly to system packaged rocks (and allow LR package depend on them (may be optional)). Also interesting direction is _sandboxing_ (like python's virtualenv and buildout do). In other words -- creating LR tree with hardwired info about "parent" trees (system, or /usr/local, or both). This extension allow us to develop more high level tools for deployment. (again -- it may not be _part_ of LR core, but LR should be friendly to this usecase) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
