Red Hat Bugzilla – Bug 440681
Review Request: luadoc - Documentation Generator Tool for Lua
Last modified: 2010-11-07 10:40:12 EST
Spec URL: http://fedorapeople.org/~timn/luastuff/luadoc.spec SRPM URL: http://fedorapeople.org/~timn/luastuff/luadoc-3.0.1.tar.gz Description: LuaDoc is a documentation generator tool for Lua source code. It parses the declarations and documentation comments in a set of Lua source files and produces a set of XHTML pages describing the commented declarations and functions. The output is not limited to XHTML. Other formats can be generated by implementing new doclets. The format of the documentation comments is also flexible and can be customized by implementing new taglets. Website: http://luadoc.luaforge.net/
Taking this review
Several problems: • rpmlint: strange permission on tarball, 0600 (binary is clean) • claims to be noarch, but installs files under %{libdir}. This is a problem as Koji will build the package only once, so %{libdir} might be /usr/lib or /usr/lib64. Can Lua, like Python, use two library paths, one for arch-independent libraries and another for arch-dependent? Otherwise, just remove the noarch
- Strange permission fixed (download was 600 by default) - Which files are in %{_libdir}? There are only files in %{_datadir}! Don't be tricked by the %{lualibdir} define, this is just part of my standard defines for Lua packages, but this package in fact does not build a C lib but only contains plain Lua files. Please re-check or name the files that happen to be in libdir when you compile (I just did new compiles for both packages and can't see a problem here). Please otherwise attached your "rpm -qpl" output of the resulting package. I have uploaded the very same SRPM again with the only change being the permissions of the source tarballs. I didn't bump the version for this so please just download the SRPM mentioned above again.
My download was 660 (using spectool -gf). Perhaps spectool fixes the permission by default. And you're correct, there was no %{_libdir} files -- sorry, I was not looking carefully.
• rpmlint: OK • package name: OK • spec file name: OK • package guideline-compliant: OK • license complies with guidelines: OK • license field accurate: OK • license file not deleted: OK • spec in US English: OK • spec legible: OK • source matches upstream: OK • builds under >= 1 archs, others excluded: noarch • build dependencies complete: OK • locales handled using %find_lang, no %{_datadir}/locale: N/A • library -> ldconfig: N/A • relocatable: give reason: N/A • own all directories: See note below • no dupes in %files: OK • permission: OK • %clean RPM_BUILD_ROOT: OK • macros used consistently: OK • Package contains code: OK • large docs => -doc: N/A • clean buildroot before install: OK • filenames UTF-8: OK SHOULD • package build in mock on all architectures: OK • package functioned as described: OK • scriplets are sane: OK • require package not files: OK Note: both luadoc and lua-logging requires lua >= 5.1, but install files under %{_datadir}/lua/5.1 . Perhaps make them also require lua < 5.2 ? Otherwise things will break when lua 5.2 is released: users might end up with dangling /usr/share/lua/5.1 directories APPROVED
Thanks for the reviews and pushing for Lua SIG.
New Package CVS Request ======================= Package Name: luadoc Short Description: Documentation Generator Tool for Lua Owners: timn Branches: F-7 F-8 InitialCC: Cvsextras Commits: yes
cvs done.
I have added an explicit provide "lua = 5.1" to the lua package. This way add-ons can depend on the exact base version that is required to have the proper package paths in place. This way we also do not have to have something like "lua >= 5.1; lua <= 5.2" which looks hackish. Since in the Lua world the base version is anyway what is looked at we should be fine with this solution.
Package Change Request ====================== Package Name: luadoc New Branches: el5 el6 Owners: timn
Git done (by process-git-requests).