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 BCADC386100A for ; Wed, 24 Feb 2021 06:53:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCADC386100A 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 Eo2ml7EkxeHr9Eo2nlBDiI; Tue, 23 Feb 2021 23:53:09 -0700 X-Authority-Analysis: v=2.4 cv=Yq/K+6UX c=1 sm=1 tr=0 ts=6035f7d5 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=TImcKGuyeGIbufSLrCcA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <874ki7uqz2.fsf@Rainer.invalid> <20210220191536.1263.50F79699@gmail.com> <20210224131805.F073.50F79699@gmail.com> From: Brian Inglis Organization: Systematic Software Subject: Re: Multiple version of Lua with alternatives Message-ID: <23c166d6-1668-f422-4b02-0c217d9224e5@SystematicSw.ab.ca> Date: Tue, 23 Feb 2021 23:53:08 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfLMuN8gnjRIp7hvnVJL2n2eHC0jc3QmynMFnDr5t6pihCyvh2XqIHEfKmymLkOuBr9ixJZg0rSPw1Lrv/Va8oNgPeKmBQcYOSo8usH5IfQlll1GvoiZN Vj8KwfmAw0pddYq4QGZ6FrRTk/k7OEse7IWWjAxELaOxHhWO6uyLpa5yvxYfYJAjDaS5Vg3/dK2UsqWUrsZAEVLOKR4n+z0+n3k= 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 06:53:12 -0000 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/local, and updated packages [1]. >> I'm wondering again it would be better for luarock to install into /usr/local >> tree. >> If we choose /usr/share/lua/luarocks as a tree root for luarocks, >> the tree will be >> /usr/share/lua/luarocks/bin >> /usr/share/lua/luarocks/lib/lua/5.3 >> /usr/share/lua/luarocks/lib/lua/5.4 >> /usr/share/lua/luarocks/lib/luarocks/rocks-5.3/ >> /usr/share/lua/luarocks/lib/luarocks/rocks-5.4/ >> /usr/share/lua/luarocks/share/lua/5.3 >> /usr/share/lua/luarocks/share/lua/5.4 >> and if we choose /usr/local, the tree will be >> /usr/local/bin >> /usr/local/lib/lua/5.3 >> /usr/local/lib/lua/5.4 >> /usr/local/lib/luarocks/rocks-5.3/ >> /usr/local/lib/luarocks/rocks-5.4/ >> /usr/local/share/lua/5.3 >> /usr/local/share/lua/5.4 >> The latter seems more intuitive for me. > usually installation with a similar subtree are installed > under usr/lib > $ find /usr/lib -name bin > /usr/lib/debug/usr/bin > /usr/lib/debug/usr/libexec/TeXmacs/bin > /usr/lib/postgresql/bin > /usr/lib/python3.8/site-packages/SCons/Tool/docbook/docbook-xsl-1.76.1/epub/bin > /usr/lib/python3.8/site-packages/SCons/Tool/docbook/docbook-xsl-1.76.1/tools/bin > /usr/lib/qt4/bin > /usr/lib/qt5/bin > /usr/lib/R/bin > /usr/lib/R/site-library/ps/bin > /usr/lib/R/site-library/Rcpp/unitTests/bin > there are few cases under usr/share > but usually are sub-sub trees > $ find /usr/share -name bin > /usr/share/doc/perl/html/html1/bin > /usr/share/gdb/auto-load/usr/bin > /usr/share/gems/gems/rake-12.3.2/bin > /usr/share/gems/gems/rdoc-6.1.2/bin > /usr/share/grace/bin > /usr/share/octave/packages/parallel-4.0.0/bin > /usr/share/octave/packages/sparsersb-1.0.8/bin > /usr/share/ruby/2.6/bundler/templates/newgem/bin > /usr/share/sgml/docbook/xsl-ns-stylesheets/epub/bin > /usr/share/sgml/docbook/xsl-stylesheets/epub/bin > /usr/share/texmf-dist/source/latex/koma-script/doc/bin > /usr/share/texmf-dist/tex4ht/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. -- 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.]