From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id E6FB13858D29 for ; Sun, 28 Feb 2021 09:34:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6FB13858D29 Received: by mail-pj1-x102d.google.com with SMTP id e9so5943610pjs.2 for ; Sun, 28 Feb 2021 01:34:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=iKZvV9VCSC2Pfnvmrq8cTXY+8ad7lmLEo54ZNCVIIo8=; b=tUIHEt0au1gQUobS2dunINdKOUw+gFg/NnKDcsu53je5H3e1g164xsg7N4E8LKhs+j /6wVGt7ZXjWdts+eYP9N/GTGW+41DUTtJ0YclpaX8Uo+TNG8jHX8aVORBZWGX2EB7+Ol iXcNdLy6moY8d2mnYGM2GvDQ43vuEI2kH8NThzNNfB1NS94orVXxHLEnQyvtyjsfFjTw hpuvBeos3mkdjsz1AKnxEtaaiEmH+HsqvBUEcHvfgi90CRFDuE8FheB0T1BcwoFU7Xos IhN/8Ab49isjANrGrA/SF9xvgGBLhjm2SpNbTUFP71e2KeuDpo9RGZm0JRfPK88gKpbz E/iA== X-Gm-Message-State: AOAM531m/2fyAY7PK/JSCec1P9Jpo4rYxeRn/5Dgq8HZxaqwOJgBypG/ LVf6rqBWA/zjpFtZn+8J+VZ3RpFmjZk= X-Google-Smtp-Source: ABdhPJxfZR+79iqT0ol39IfcwM2A8gMGqVwOm196+l/z9lNbg6qWxQ6KAWDuBYwmPpMvw+9QDHF+hg== X-Received: by 2002:a17:902:a9cb:b029:e2:f64e:b778 with SMTP id b11-20020a170902a9cbb02900e2f64eb778mr10601256plr.39.1614504877504; Sun, 28 Feb 2021 01:34:37 -0800 (PST) Received: from [192.168.3.4] ([2400:2411:aa20:4300:a024:26ee:97c7:8a25]) by smtp.gmail.com with ESMTPSA id lr7sm3772087pjb.17.2021.02.28.01.34.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2021 01:34:35 -0800 (PST) Date: Sun, 28 Feb 2021 18:34:36 +0900 From: Lemures Lemniscati To: cygwin-apps@cygwin.com Subject: Re: Multiple version of Lua with alternatives In-Reply-To: <878s79k7x6.fsf@Rainer.invalid> References: <20210227171327.39AC.50F79699@gmail.com> <878s79k7x6.fsf@Rainer.invalid> Message-Id: <20210228183433.AF5A.50F79699@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.75.02 [ja] X-Antivirus: Avast (VPS 210227-8, 2021/02/28), Outbound message X-Antivirus-Status: Clean X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Sun, 28 Feb 2021 09:34:40 -0000 On Sat, 27 Feb 2021 13:32:37 +0100, Achim Gratz > Lemures Lemniscati via Cygwin-apps writes: > >> > I've understood that we should avoid /usr/local. > > Specifically we should avoid to put files or directories there, so if > you ever envision to have luarocks wrapped up as Cygwin packages that is > definitiely the wrong place for them to end up at. OTOH, if you think > of luarocks as things that only ever exist locally, then it might be OK > (but even the empty directory must not be packaged). > > >> > And, choices for a tree-prefix where luarocks will install rocks are: > >> > 1) luarocks_tree=/usr/share/lua/luarocks > > That only makes sense if luarocks aren't architecture specific. In > other words if you had multiple lua installations of the same version > targeting different architectures and they could all share the exact > same luarocks, then these should be installed into that location. A problem is that ${luarock_tree} can contain both architecutre-independent components and -specific ones, and that components in ${luarocks_tree}/bin might be architecture-specfic or architecture-independent. Architecture-specific (scripts under bin might be architecture-independent): ${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/ Architecture-independent: ${luarocks_tree}/share/lua/5.3 ${luarocks_tree}/share/lua/5.4 Then, although I don't know it can be easily configured, here might be candidates to separate architecture-specific and -independent components: (A) simply using mixed tree prefixes luarocks_tree=/usr/lib/lua/luarocks ${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=/usr/share/lua/luarocks ${luarocks_tree}/share/lua/5.3 ${luarocks_tree}/share/lua/5.4 (B) using mixed tree prefixes and removing tautological directories luarocks_tree=/usr/lib/lua/luarocks ${luarocks_tree}/bin ${luarocks_tree}/5.3 ${luarocks_tree}/5.4 ${luarocks_tree}/rocks-5.3/ ${luarocks_tree}/rocks-5.4/ luarocks_tree=/usr/share/lua/luarocks ${luarocks_tree}/5.3 ${luarocks_tree}/5.4 Other suggestions are welcome. Regards, Lem