Re: [ANN] The LEM Project

[Sean Conner <sean@...>]

It was thus said that the Great Jay Carlson once stated:
> On May 27, 2014 9:20 PM, "Sean Conner" <sean@conman.org> wrote:
> 
> > One problem:
> > what if LuaRocks did [2]:
> >
> >         f = io.open("config.lua","r+")
> >
> > which opens f in read/write mode.  Does that imply the file is updated in
> > the LEM file?
> 
> I think you will drive .lem distributors (and yourself) crazy with bug
> reports against mysterious failures modes, ones which are hard to name or
> specify. The sha256sum[1] of a distributed file, especially an executable
> one, should not change. If it does, I have to keep the downloaded .tar.xz
> file around if for no other reason than to re-extract to reset.

  So I take that as a "no" then.  Okay.

> Consider the xdg-basedir spec for paths, by the way.

  That's fine for Linux.  What about other systems though?  XDG_DATA_HOME
defaults to "$HOME/.local/share" which doesn't sound like it would play well
with Windows.  

> Speaking of "driving crazy with bug reports" there are a bunch of things
> which sift through archives besides developers. Antivirus software can
> freak out at not-quite-normal archives, especially when they appear to be
> internally damaged. I can freak out when an unzip into a fresh directory
> prompts me about overwrites. Please do not ship archives with multiple
> members with the same name. You can pretend there are platform-appropriate
> directory symlinks when your resolver code runs.

  The intent is to run Lua code directly from this file.  Yes, it's a ZIP
format, and it follows the standard.  I can't help it if, by following the
standard, some fool anti-viral program chokes on it.  

> [1]: I still say "md5" as slang for a cryptographic hash when I mean, you
> know, an actual general-purpose cryptographic hash. Saying "md5" is a bad
> habit, and it makes me sound old. Anyway, if you disturb an md5 you will
> also disturb sha256 and any HMAC. You won't necessarily disturb jar signing
> but I'm trying not to turn this into "steal all the jar infrastructure by
> avoiding incompatibility unless really important." Well, maybe I am a
> little.

  Hmm ... I only know jar files by concept.  I don't actually work with them
all that much.  

  -spc