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 > 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? -- -- Hisham http://hisham.hm/ - http://colorbleed.com.br/ ------------------------------------------------------------------------------ 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
