 |
lua-l archive |
|
|
||
|
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.
Consider the xdg-basedir spec for paths, by the way.
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.
Jay
[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.