From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) by sourceware.org (Postfix) with ESMTPS id 5677238708EC for ; Wed, 24 Feb 2021 16:38:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5677238708EC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([68.147.0.90]) by shaw.ca with ESMTP id ExBKlA99weHr9ExBLlE4JC; Wed, 24 Feb 2021 09:38:35 -0700 X-Authority-Analysis: v=2.4 cv=Yq/K+6UX c=1 sm=1 tr=0 ts=6036810b a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=AW2qQE7oAAAA:8 a=vTr9H3xdAAAA:8 a=ObcLf_uJAAAA:20 a=Br9LfDWDAAAA:8 a=6M_dfDrfAAAA:8 a=fxJcL_dCAAAA:8 a=yBR9Qs6oAAAA:8 a=eDriXhb0AAAA:8 a=yQc1UE_UOS_X039eyMEA:9 a=QEXdDO2ut3YA:10 a=tXPN41UFbj8aQYus5oxy:22 a=7PCjnrUJ-F5voXmZD6jJ:22 a=gR_RJRYUad_6_ruzA8cR:22 a=-RP_3b4F4lPIh3iPpEQP:22 a=7C5qix1daMSKwVux_nGC:22 a=mvUXoWGB5xU-umoAxWMh:22 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <23c166d6-1668-f422-4b02-0c217d9224e5@SystematicSw.ab.ca> <20210224200321.589E.50F79699@gmail.com> From: Brian Inglis Organization: Systematic Software Subject: Re: Multiple version of Lua with alternatives Message-ID: <42e545cf-2a49-f5e2-f75b-0f9ed7f2ac7a@SystematicSw.ab.ca> Date: Wed, 24 Feb 2021 09:38:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210224200321.589E.50F79699@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfLFoRDyx3k5Di8d8d+u2NjkzWP5kW9BIKpo0S/CZcEndFfShyUfBAMiOCtAdd/WGWeZbHeG4ua4/kTCxoUndZF294SdNQa/g/LkfybpQ/ABVEKWTfoqc OBfXh373O4SyD42LGBzPUrQ68VRReLIXh0pkPD9U81O8i558A+GAdntz1wDFt03RfPx9mfEbPhZrTLP230njQHVexGDHjk7CEcw= X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 16:38:38 -0000 On 2021-02-24 04:03, Lemures Lemniscati via Cygwin-apps wrote: > On Tue, 23 Feb 2021 23:53:08 -0700, Brian Inglis >> On 2021-02-23 22:20, Marco Atzeri via Cygwin-apps wrote: >>> On 24.02.2021 05:18, Lemures Lemniscati via Cygwin-apps wrote: >>>> On Sat, 20 Feb 2021 19:15:38 +0900, Lemures Lemniscati >>>>> On Sat, 20 Feb 2021 08:40:33 +0100, Achim Gratz >>>>>> Lemures Lemniscati via Cygwin-apps writes: >>>>>>> * A new source luarocks provides lua53- and lua54-luarocks. >>>>>>>    They install rocks into an alternative tree /var/lib/lua-site/. >>>>>> That looks wrong to me, I'd have expected >>>>>> /usr/share/lua/luarocks >>>>>> or maybe /usr/local as a prefix depending on how much emphasis you want >>>>>> to put on the user-installable part.  The /var/lib tree is for local >>>>>> state information per FHS, not installed components. >>>>> Thank you for review. >>>>> I've fixed it, so that luarocks should install rocks into >>>>> /usr/share/lua/luarocks, and updated packages [1]. > ^^^^^^^^^ (Sorry I accidentally replaced it by '/usr/local' in the > original mail: it is still /usr/share/lua/luarocks ) >>>> I'm wondering again it would be better for luarock to install into /usr/local >>>> tree. >>> usually installation with a similar subtree are installed >>> under usr/lib >>> $ find /usr/lib -name bin >>> there are few cases under usr/share >>> but usually are sub-sub trees >>> $ find /usr/share -name bin >>> we have nothing "current" installed under usr/local >>> at all. No package should be installed there >> Indeed - that's where I stash all my personal Cygwin scripts and exes. >> Another good spot is /usr/libexec/ which is well populated by the likes of >> git plumbing and other packages. I prefer the packages that populate >> subdirectories rather than littering the top level like geoclue and gvfsd. > Thank you for advices! > I've understood that we should avoid /usr/local. > And, choices for a tree-prefix where luarocks will install rocks are: > 1) luarocks_tree=/usr/share/lua/luarocks > 2) luarocks_tree=/usr/lib/lua/luarocks > 3) luarocks_tree=/usr/libexec/lua/luarocks > And rocks will go: > ${luarocks_tree}/bin > ${luarocks_tree}/lib/lua/5.3 > ${luarocks_tree}/lib/lua/5.4 > ${luarocks_tree}/lib/luarocks/rocks-5.3/ > ${luarocks_tree}/lib/luarocks/rocks-5.4/ > ${luarocks_tree}/share/lua/5.3 > ${luarocks_tree}/share/lua/5.4 > I don't know which is the best. > Current choice is still /usr/share/lua/luarocks [1]. > [1]: https://cygwin-lem.github.io/lua-cygwin-packages/ Packaging luarocks varies across distros. Where I have been able to find target directories suggests: basing off Fedora as much here does: https://src.fedoraproject.org/rpms/luarocks/blob/rawhide/f/luarocks.spec#_57: mkdir -p %{buildroot}%{_prefix}/lib/luarocks/rocks-%{lua_version} would suggest /usr/lib/luarocks/rocks-%{lua_version} msys2 uses: https://github.com/msys2/MINGW-packages/blob/fbe23378fcb1fa50dcd132ce8ab24217a6d9e433/mingw-w64-lua-luarocks/luarocks-x86_64.install#L8 ${MINGW_PREFIX}/share/lua/5.1/luarocks/site_config.lua /usr/share/lua/$VER/luarocks/ Arch uses: https://archlinux.org/packages/community/any/luarocks/ usr/share/lua/$VER/luarocks/ slack uses: https://slackbuilds.org/slackbuilds/14.2/development/luarocks/luarocks.SlackBuild#77 suggests /usr/lib{,64}/ and whatever make install defaults to. Ubuntu uses: https://packages.ubuntu.com/groovy/all/luarocks/filelist /usr/share/lua/$VER/luarocks/ [Note: repology.org and wikidata.org link each other for useful package info] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]