| Summary: | new ebuild: dev-util/luarocks | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Natanael Copa <natanael.copa> |
| Component: | New packages | Assignee: | Matti Bickel (RETIRED) <mabi> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | asb, mabi |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.luarocks.org | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
luarocks-0.4.ebuild
luarocks-0.4-configure.patch luarocks-0.5.2.ebuild Update ebuild to latest release ebuild for luarocks 1.0 Updated 1.0 version |
||
|
Description
Natanael Copa
2008-01-25 09:13:34 UTC
Created attachment 141752 [details]
luarocks-0.4.ebuild
Created attachment 141754 [details, diff]
luarocks-0.4-configure.patch
replace some write-only shell/sed code that faild on uclibc anyway, with POSIX compliant shell code.
is also submitted upstream.
Sounds cool. I'll get me up2date with how gentoo runs the CPAN system alongside with the package managers. If that's compatible with luarocks, i'll get it in the tree. Thanks for the work :) Created attachment 156039 [details]
luarocks-0.5.2.ebuild
I've just attached an ebuild for luarocks 0.5.2. I've tried to choose the install paths based on the guidance given in the Dev Manual and the choices available in the default lua search path.
Global luarocks configuration goes to etc/luarocks/config.lua, the luarocks
.lua files will be installed to /usr/share/lua/5.1/luarocks/. The global
luarocks path for rocks installed by the root user is /usr/local/lib/luarocks.
Due to the default lua search path, the only possible locations for luarocks
to install itself (and be found by the lua interpreter) are
/usr/local/share/lua/5.1, /usr/local/lib/lua/5.1 and /usr/share/lua/5.1 - as
portage isn't supposed to install things to /usr/local, the third option is
the only viable one (though I'm aware ruby gems installs in /usr/lib/ruby).
The global rocks tree could really go anywhere, but I think it makes sense
that user-installed rocks go into /usr/local which is kept for non-portage
applications.
I believe I've caught all the dependencies. wget and md5sum are both required at run-time, but are part of system so I don't depend on them.
It's my intention is that this ebuild is in a state where it could be added to the portage tree. If it is deficient in any way, please give me feedback.
Created attachment 160847 [details]
Update ebuild to latest release
Created attachment 164330 [details]
ebuild for luarocks 1.0
I've verified this ebuild with luarocks 1.0, hopefully it can find its way into portage.
Created attachment 168746 [details]
Updated 1.0 version
Hi, i spent some time figuring out what the best way to do it actually is.
I very much agree with your ebuild, and had just a few minor modifications. I'm posting the version i've tested now.
Quite unsure about the --rocks-tree parameter, as this seems to install /usr/lib/lua/rocks/rocks when first used. Can you explain this? In any case, i'd like to mimic what gems does, as the installed rocks should be easily found by lua and be kept away from /usr/local - that's my view of "software installed using portage NEVER touches /usr/local". It also keeps in line with what ruby gems do.
If that's fine with you, this version will enter the tree within a week.
Thanks for your persistance and help with that. I'd be glad if you could keep an eye open for updates, etc. in case i miss them.
(In reply to comment #7) > Created an attachment (id=168746) [edit] > Updated 1.0 version > > Hi, i spent some time figuring out what the best way to do it actually is. > I very much agree with your ebuild, and had just a few minor modifications. I'm > posting the version i've tested now. > Quite unsure about the --rocks-tree parameter, as this seems to install > /usr/lib/lua/rocks/rocks when first used. Can you explain this? In any case, > i'd like to mimic what gems does, as the installed rocks should be easily found > by lua and be kept away from /usr/local - that's my view of "software installed > using portage NEVER touches /usr/local". It also keeps in line with what ruby > gems do. > > If that's fine with you, this version will enter the tree within a week. > > Thanks for your persistance and help with that. I'd be glad if you could keep > an eye open for updates, etc. in case i miss them. > On the issue of installing to /usr/local, I was going to point to the devmanual suggesting that /usr/local be used for non-portage applications[1] - clearly anything installed via luarocks is not managed by portage. However, this is just a personal preference and matching what rubygems does seems very sensible. For your /usr/lib/lua/rocks/rocks question, that's because the rocks tree by default might also include installed scripts. For instance, my local rocks tree ~/.luarocks contains the directories rocks/ and bin/. The rocks tree is really just a directory completely managed by luarocks. For this reason, I think a --rocks-tree of /usr/lib/lua/luarocks would be better. Certainly we don't expect a bin directory in the rocks tree as we've specified an alternative, but a future luarocks version might change the rocks tree layout so we wouldn't want to cause future upgrade problems by just setting a rocks-tree of /usr/lib/lua on the assumption that only the rocks/ dir will be created. On the topic of the bin directory, I might consider using /usr/local/bin but I don't know what other managers do. In summary, your ebuild looks like an improvement to me but I think /usr/lib/lua/luarocks is a slightly more sensibly named rocks tree. Thanks for taking a look at this ebuild, I'm looking forward to luarocks making it into portage. [1]: http://devmanual.gentoo.org/general-concepts/filesystem/index.html I just comitted the package to the tree. If you find any bugs or updates, please let me know. Marking this bug as fixed as ebuild is in tree. Many thanks for your efforts! |
