On Sun, Sep 9, 2012 at 10:52 AM, Alexander Gladysh <[email protected]> wrote: > On Sat, Sep 8, 2012 at 6:13 AM, Hisham <[email protected]> wrote: >> On Fri, Sep 7, 2012 at 9:59 AM, Alexander Gladysh <[email protected]> wrote: >>> On Sun, Sep 2, 2012 at 12:54 AM, Alexander Gladysh <[email protected]> >>> 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.
Understood. That is indeed a problem. > 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. This is not a problem specific to cmake. Nothing stops one from writing a Makefile that runs git or wget, too. The only rockspecs you can be "statically sure" that don't pull anything at build-time are the builtin ones. I try to make this unnecessary for rock writers, by supporting various download systems. From this situation, I guess we need to add support for git submodules. And maybe a "no-downloads-at-build-time" policy for .src.rock files from the main repo should be established. > Poked (offline, neither of forks do have GH Issues enabled, unfortunately). Thanks, -- Hisham ------------------------------------------------------------------------------ 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
