On Sat, Sep 8, 2012 at 6:13 AM, Hisham <h...@hisham.hm> wrote: > On Fri, Sep 7, 2012 at 9:59 AM, Alexander Gladysh <aglad...@gmail.com> wrote: >> On Sun, Sep 2, 2012 at 12:54 AM, Alexander Gladysh <aglad...@gmail.com> >> wrote:
>> The error seems to be fixed in one of the lua-http-parser forks (by >> switching the http-parser Git submodule to an alternative repo). Is it >> possible to get that fix to LR? > > I uploaded an "scm" rock to the rocks-scm repository which works. Thanks! > The reason why it wasn't posted to the main rocks repository is > because there is no upstream (or fork) _version_ containing the fix. > Rockspecs in the main repo are all versioned, ie, they must point to a > specific, non-moving-target version for download. Normally, when the > original source code goes missing (or moves around to a different URL) > that's not a problem because we keep a copy of the sources as a > .src.rock file, but the rockspec in case is downloading extra sources > at build time, so there's nothing LuaRocks can do to protect itself at > this point. Ouch. Shouldn't this be frowned upon? I know that you have policy to keep entry barriers minimal, but this particular behaviour is not nice to the users. We have a strict policy that requires us to store all foreign LR dependencies locally (which paid off during recent outage BTW). This policy makes lua-html-parser rock unusable for us, since we *can't* store its .src.rock in a way that it will be self-contained. Worse, apparently, we can't know now if *any* cmake-enabled .src.rock we have is self-contained. The only option we have is to forbid cmake rock dependencies. So, would it be possible to: 1) Add a config setting that will disable cmake's feature that downloads code? 2) Force such rocks to be self-contained somehow upon acceptance to the LR repo? 3) Add a config setting that will disable cmake altogether (while keeping cmake in the system)? 4) Clearly mark build system in the rocks html index, for each rockspec? > I suggest you to poke upstream and ask them to tag the current git > tree as 1.0.1 or something, that would suffice for us to pack a > versioned release in the main repo. Poked (offline, neither of forks do have GH Issues enabled, unfortunately). With best regards, Alexander. ------------------------------------------------------------------------------ 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
