On Thu, Sep 13, 2012 at 01:26:30PM +0600, Ildar Mulyukov wrote: > Ok. Now let's look at some things that may lead us to the right > direction. Those are: $LUA_PATH, RPM/DEB. > > 1. $LUA_PATH (similar to $PATH, $LD_LIBRARY_PATH): > 1. allows access to lua libraries that are placed in multi-trees. > 2a. do not imply any rules on where files should be put. > 2b. do not control dependencies > 2c. do not have/need any cache files (ld.so has ld.so.cache but > that's optional) > 2. RPM/DEB > 1. cannot handle multi-tree (at one shot). > I myself can't remember any other Package Management System > supporting multi-tree. (BSD-ish maybe? I don't know.) > 2a. have rules where to put files (mainly according to FHS(1)) > 2b. strong in controlling deps > 2c. have DB which is mandatory. > > So speaking of LR, if it's a Package Management System, then it > probably shouldn't handle multi-trees in terms of deps checking. PERIOD. >
Major problem of LR -- LR pretends to be a Package Management System, but it is not a package management. It completely orthogonal to system package managers, and doesn't interact with them in any cases. (It is not only LR problems -- python and ruby package managers have similiar caveats) > But if treating LR as "packaging of what is in $LUA_PATH", then there > could be an alternative design: > 1. LR follows $LUA_PATH and handles multi-tree according to it. > $LUA_CPATH should be taken into account too. We now treat /etc/luarocks/config.lua in similiar way. I have some intentions to use per-project config.lua for sandboxing (with splitting on system-wide installed rocks, and project local rocks) > 2a. -||- > 2b. LR shall control deps. > 2c. manifest file existence and placement should be rethought. > > Need to elaborate further. But for now what do you think? > Originally patch was developed as workaround to two major problems. 1) Luarocks have problems in multiarch environment (ie recent ubuntu -- precise) -- few binary rocks requires lib*-dev even for installing prebuilt rocks. 2) We have problem with system-level dependencies, LR+rockspecs allow us to check dependencies on shared libraries, but not pull them. I make effort to package rocks into individual debian packages, using gem2deb and python-stdeb as proof-of-concept and reference implementation. But without patch we can't use /usr/local and in-home rocks trees in conjuction with system provided rocks. Maybe we should formalize list of rocks trees in config file? (declare -- which trees can participate in dependency resolving, which trees managed by external tools (dpkg, rpm and their friends), etc) ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
