我正在处理我的第一个lua包装，我对于我的rockpec（s）的名称以及放置它们的位置感到非常困惑。我看到的每一个流行的lua包似乎都不同地处理了rockspecs。这与Ruby非常不同，其中每个gem只有一个gemspec。以下是一些例子：
lua_cliargs-3.0-1.rockspec）scm而不是版本号命名（例如ldoc-scm-2.rockspec）rockspec/目录中的多个版本命名的rockspec（例如lua-messagepack-0.1.0-1.rockspec，... lua-messagepack-0.3.4-1.rockspec），其次是一些在包版本之前插入额外的lua版本（例如lua-messagepack-lua53-0.3.6-1.rockspec）。有时相同的包版本有两个rockspecs，一个包含lua53而另一个不包含。/rockspec目录中的多个版本命名的rockspec（例如luafilesystem-1.3.0-1.rockspec，... luafilesystem-1.6.1-1.rockspec），其次是一些cvs代替在软件包版本之前插入的软件包版本号（例如luafilesystem-cvs-1.rockspec，luafilesystem-cvs-2.rockspec）。scm而不是包编号（例如luasocket-scm-0.rockspec），和包含/rockspec目录的一个rockspec包含包含编号的单个rockspec（例如luasocket-3.0rc2-1.rockspec）现在，this question解释了为什么会有一个＆＃34;工作＆＃34; rockspec文件和一个单独的目录充满了发布版本的rockspecs，但我还有几个问题：
lpeg如何在luarocks上列出，但缺少rockspec？scm应该用来代替包版本号。但是由于HEAD不断变化，而且必须列出所有文件，所以似乎需要不断增加revision个scm个数量的scm来跟上添加或删除任何文件。人们可以通过不使用ldoc-scm-2.rockspec rockspecs的版本号来解决这个问题，但我看到的那些版本编号很低（例如$agematch = Agency::where('Age', 'like', Auth::user()->Age)->get();
）。这是一个错误吗？答案 0 :(得分：6)
什么是rockpec修订版？
rockspec修订版是rockspec文件本身的版本控制。假设你发布了Foo 1.0版;你创建了一个rockspec foo-1.0-1.rockspec。后来你了解到要在FreeBSD中编译Foo 1.0，你需要传递一个额外的-D标志;源代码根本不需要任何更改。您可以编辑rockspec添加platform override section并将其重新提交到luarocks.org foo-1.0-2.rockspec。
如果我的rockspec在VCS中，并且我标记了一个特定的提交，那么这不能有效地修复该提交中包含的rockspec（s）吗？因此版本？
是。但这不是问题，因为建造时使用的rockspec不是源分布中包含的。 .src.rock文件是一个存档，其中包含已提交的.rockspec文件和源代码tarball（如果rockspec使用SCM协议（例如git://，则会在子目录中进行源检出） ）。
实际上，这会导致鸡蛋和鸡蛋问题，因为当从Github手动检出标签v1.0时，Foo 1.0的最新版本不存在，但这不是预期的工作流程：使用时LuaRocks，用户通常会使用luarocks install foo;如果他们想要查看一个项目的岩石规格，他们可以在luarocks.org访问Foo的页面，或者他们会查看存储在HEAD中的rockspecs，这是人们最先停下来的地方。
请注意，如果想要分发包含rockspec的源tarball，然后想要在rockspec中设置tarball source.url及其对应的source.md5，则会发生类似的鸡与蛋的情况。拥有MD5意味着rockpec本身不能在tarball内部。解决它的一种方法是简单地避免source.md5字段，或者在打包tarball时跳过rockspec。这与在上游tarball中包含Linux发行包元数据的情况相同;这里更明显，因为上游和打包者往往是同一个人。
如何将lpeg列在luarocks上但缺少一个rockpec？
可能是因为这是一个罕见的情况，上游和打包者不是同一个人。 Roberto Ierusalimschy发布了lpeg，但截至2016年12月，它的岩石由Gary Vaughan上传。
[...]我看到的那些修订号很低（例如ldoc-scm-2.rockspec）。这是一个错误吗？
这可能有很多原因，也可能是错误。
make内容，那么添加或删除文件时scm rockspec可能不会更改; scm rockspecs保留在-0（如“不是已发布的版本”），并且永远不会将它们上传到luarocks.org（仅保留已发布的版本）。因此，获取git修订版时获得的版本是该快照的有效版本。增加修订是针对发布到luarocks.org; 以上任何一个例子都被认为是最佳做法吗？
客观地说，由于运行luarocks install foo时使用的rockspec文件是捆绑在.src.rock文件中的文件，与源档案分开存储，因此对于确切位于何处的文件没有重大的实际后果源代码树开发人员存储他们的rockspecs。这是个人组织的问题。
在根目录中保留最新的scm rockspec具有轻微优势，如果想要从本地签出树进行构建，则luarocks make会自动获取它。
但只要使用luarocks upload foo将rockspecs上传到服务器，最终用户体验就会相同，无论源树中的岩石规格在哪里。