On Tue, Jul 12, 2011 at 12:23 AM, Alexander Gladysh <[email protected]> wrote: > 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.
Sorry to hear about that, but it's not my responsibility to make LuaRocks work out of the box for every user all the time for every distribution change. I provide sensible Unix defaults that work for everyone else (and have worked for Ubuntu for years) and I go out of my way to make things configurable in LuaRocks so that even when things like this happen, users have an option to have a working system. > This is a problem of small and proud LuaRocks, not a problem of Debian > or Ubuntu. LuaRocks is fine and Ubuntu is fine. You've been told how to make them work properly. If the value was "hardcoded" as you falsely stated in StackOverflow, I would have provided a fix. But it is configurable. If you refuse to configure the software, there is nothing I can do. Sorry, -- -- Hisham http://hisham.hm/ - http://colorbleed.com.br/ ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
