On Tue, Jul 12, 2011 at 00:45, Hisham <[email protected]> wrote: > On Mon, Jul 11, 2011 at 5:13 PM, Alexander Gladysh <[email protected]> wrote: >> On Tue, Jul 12, 2011 at 00:05, Hisham <[email protected]> wrote: >>> On Mon, Jul 11, 2011 at 6:18 AM, Alexander Gladysh <[email protected]> >>> wrote: >>>> On Mon, Jul 11, 2011 at 08:21, Alexander Gladysh <[email protected]> >>>> wrote: >>>>> On Mon, Jul 11, 2011 at 08:18, Alexander Gladysh <[email protected]> >>>>> wrote: >>>>>> On Mon, Jul 11, 2011 at 07:08, Alexander Gladysh <[email protected]> >>>>>> wrote: >>>>>>> Installation of luuid rock fails on Ubuntu 11.4 because libuuid.so >>>>>>> moved from /usr/lib to /usr/lib/i386-linux-gnu/ (I suspect that this >>>>>>> directory is arch-dependent). >>>>> >>>>>>> Can something be done about this, please? >>>>> >>>>>> See here: >>>>>> http://askubuntu.com/questions/52617/usr-lib-i386-linux-gnu/52619#52619 >>>>> >>>>>> (Each Ubuntu release breaks something horribly... :( ) >>>>> >>>>> This stuff breaks my deployment. :-( >>>>> >>>>> Hisham, is it possible to release 2.0.4.2 with a fix? >>>>> >>>>> Also, is it possible for LR to eventually use some system .so lookup >>>>> mechanics somehow? >>>> >>>> People suggest that, to be more robust, LuaRocks should use ld.so.conf >>>> and ld.so.conf.d contents to determine proper places where to look for >>>> .so files. >>>> >>>> It is not good at all that random distributive updates break luarocks :( >>> >>> Distributions can break things any way they please. I try to be >>> reasonable, but we can't go changing their defaults for all of them >>> and making emergency releases whenever Ubuntu decides to break the >>> world. I don't even think ld.so.conf.d is a standard directory. The >>> latest version of Binutils, 2.21.1, has no reference to it *at all* in >>> its sources or binaries (I just upgraded to the latest version, >>> vanilla build straight from the GNU tarball, just to be sure). >> >> Well, no official fix means that I'm forking LR now and leaving it >> ASAP. No big deal for the rest of the world, of course. > > Just because a default value (which was explicitly designed to be > configurable through the configuration file) does not match the value > you want, do you consider it broken and needing a fix? I guess we have > different
For me, as a user, LuaRocks *is* broken. It does not work on my system out of the box. I do not care much to re-configure it on every single machine I have, just because you strive for some virtual purity / simplicity reasons. This is a problem of small and proud LuaRocks, not a problem of Debian or Ubuntu. >> Maybe you will at least deign to update the lookup logic so that >> standard LHS directories are included? >> >> /lib*/ >> /opt/*/lib*/ >> /usr/lib*/ >> /usr/local/lib*/ > > Where in the FHS does it say that this is the specified list of > directories? I see only /lib, /lib<qual>, /opt/<package>/lib/, > /usr/lib, /usr/lib<qual> and /usr/local/lib there. (A valid > possibility to improve LuaRocks would be to add multiarch support to > handle /usr/lib64, but how to do this cleanly is an open issue > (perhaps the cleanest solution is simply to adequately configure two > instances of LuaRocks when required.) ) >> (Note recursive *) > And where in the FHS does it say that the lookup logic in these > directories should be recursive? Sorry, I must have re-read the source before posting this part. Indeed, no such thing, my bad. OK, alternatively: what about calling dlopen() on a library instead of looking for it in the filesystem, as people suggest on SO? Alexander. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
