[PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Lemures Lemniscati]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Hi!

This is a fixed patch for cygport:

I'd like to apply alternatives to lua packages to have different
versions of lua being installed. But, in such cases, current
__list_deps() might pick wrong dependencies.

And, this is a patch to add a flag __SKIP_LIST_DEPS_LUA to skip
__list_deps() detecting depedency on lua, for the time being.

I think it will do no harm.


Regards,

Lem


diff --git a/lib/pkg_info.cygpart b/lib/pkg_info.cygpart
index 98f7808..1b27b61 100644
--- a/lib/pkg_info.cygpart
+++ b/lib/pkg_info.cygpart
@@ -331,7 +331,14 @@ __list_deps() {
 		done
 	fi
 
-	if check_prog lua
+#****v* Information/__SKIP_LIST_DEPS_LUA
+#  DESCRIPTION
+#  A flag in __list_deps() to skip detecting depedency on lua.
+#  Set a nonempty string to __SKIP_LIST_DEPS_LUA in order to skip.
+#  (e.g. in case Lua's of different versions exist).
+#****
+
+	if [ -z "${__SKIP_LIST_DEPS_LUA}" ] && check_prog lua
 	then
 		luapaths=($(lua -e 'print(package.path..";"..package.cpath)' | tr '\;' ' '))
 		luapaths+=" ${DEPS_PATH//:/ }"
-- 
2.30.0


[-- Attachment #2: 0001-Add-a-flag-__SKIP_LIST_DEPS_LUA-to-skip-detecting-de.patch --]
[-- Type: application/octet-stream, Size: 899 bytes --]

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Lemures Lemniscati <lemures.lemniscati@gmail.com>
Date: Fri, 15 Jan 2021 18:52:44 +0900
Subject: [PATCH] Add a flag __SKIP_LIST_DEPS_LUA to skip detecting depedency


diff --git a/lib/pkg_info.cygpart b/lib/pkg_info.cygpart
index 98f7808..1b27b61 100644
--- a/lib/pkg_info.cygpart
+++ b/lib/pkg_info.cygpart
@@ -331,7 +331,14 @@ __list_deps() {
 		done
 	fi
 
-	if check_prog lua
+#****v* Information/__SKIP_LIST_DEPS_LUA
+#  DESCRIPTION
+#  A flag in __list_deps() to skip detecting depedency on lua.
+#  Set a nonempty string to __SKIP_LIST_DEPS_LUA in order to skip.
+#  (e.g. in case Lua's of different versions exist).
+#****
+
+	if [ -z "${__SKIP_LIST_DEPS_LUA}" ] && check_prog lua
 	then
 		luapaths=($(lua -e 'print(package.path..";"..package.cpath)' | tr '\;' ' '))
 		luapaths+=" ${DEPS_PATH//:/ }"
-- 
2.30.0

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Achim Gratz]

Lemures Lemniscati via Cygwin-apps writes:
> This is a fixed patch for cygport:
>
> I'd like to apply alternatives to lua packages to have different
> versions of lua being installed. But, in such cases, current
> __list_deps() might pick wrong dependencies.
>
> And, this is a patch to add a flag __SKIP_LIST_DEPS_LUA to skip
> __list_deps() detecting depedency on lua, for the time being.

Your patch is overshooting your goal I'd think.  What you likely want
instead is to specify which lua to use in setting up the luapaths
variable so that the correct dependencies get extracted.

> I think it will do no harm.

For a more general facility of suppressing unwanted dependencies see:

https://repo.or.cz/cygport/rpm-style.git/commitdiff/83b4df817b81fe39257e59fe882b76ca18a80d7c
https://repo.or.cz/cygport/rpm-style.git/commitdiff/d447a7553d93390f7eb3814216640ea6a2afdd4a

I needed this specifically for being able to split the perl_base package
off perl and switching from manual to automatic generation of the
dependency on the perl5_0xy provide.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Lemures Lemniscati]

On Fri, 15 Jan 2021 21:02:25 +0100, Achim Gratz
> Lemures Lemniscati via Cygwin-apps writes:
> > This is a fixed patch for cygport:
> >
> > I'd like to apply alternatives to lua packages to have different
> > versions of lua being installed. But, in such cases, current
> > __list_deps() might pick wrong dependencies.
> >
> > And, this is a patch to add a flag __SKIP_LIST_DEPS_LUA to skip
> > __list_deps() detecting depedency on lua, for the time being.
> 
> Your patch is overshooting your goal I'd think.  What you likely want
> instead is to specify which lua to use in setting up the luapaths
> variable so that the correct dependencies get extracted.
> 
> > I think it will do no harm.
> 
> For a more general facility of suppressing unwanted dependencies see:
> 
> https://repo.or.cz/cygport/rpm-style.git/commitdiff/83b4df817b81fe39257e59fe882b76ca18a80d7c
> https://repo.or.cz/cygport/rpm-style.git/commitdiff/d447a7553d93390f7eb3814216640ea6a2afdd4a
> 
> I needed this specifically for being able to split the perl_base package
> off perl and switching from manual to automatic generation of the
> dependency on the perl5_0xy provide.

Thank you, Achim.

I think it is what I'm longing for.
And it works.



What I'd like to do is to have both lua5.3 and lua5.4 be installed, and
alternatives make a symbolic link to lua5.3 or lua5.4  (new packages
lua5.3-5.3.6-1 and lua5.4-5.4.2-1 which I try packaging.
And I'm trying to package luarocks for lua5.3 and lua5.4
(lua5.3-luarocks and lua5.4-luarocks) by a single cygport file.

Regards,

Lem

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[ASSI]

Lemures Lemniscati via Cygwin-apps writes:
> What I'd like to do is to have both lua5.3 and lua5.4 be installed, and
> alternatives make a symbolic link to lua5.3 or lua5.4  (new packages
> lua5.3-5.3.6-1 and lua5.4-5.4.2-1 which I try packaging.

Multi-version installations are not well supported by setup or cygwin
yet, but the alternatives anyway only address the question of how to set
the default version for the user.  For building packages you'd need to
specify which version to use each time you build something, so any
occurences of plain "lua" (from PATH) would need to be replaced with the
expansion of some variable that would be set appropriately when entering
pkg_info.

> And I'm trying to package luarocks for lua5.3 and lua5.4
> (lua5.3-luarocks and lua5.4-luarocks) by a single cygport file.

The packages should be named lua53-luarocks and lua54-luarocks (no dot
in the version number), like OpenSUSE (they seem to be the only
distribution with a multi-version lua and that particular naming scheme
you've chosen).

A different question is if you really want to package this particular
feature.  Just like all the other "package managers" that come with a
specific language or interpreter I'd expect this one to need (maybe
extensive) modifications to work correctly on Cygwin, especially if it
ends up building dynamic objects.  That's one reason I discourage the
use of CPAN on Cygwin, since folks tend to shoot themself into the foot
more often than not by using it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Lemures Lemniscati]

On Sat, 16 Jan 2021 07:50:52 +0100, ASSI
> Lemures Lemniscati via Cygwin-apps writes:
> > And I'm trying to package luarocks for lua5.3 and lua5.4
> > (lua5.3-luarocks and lua5.4-luarocks) by a single cygport file.
> 
> The packages should be named lua53-luarocks and lua54-luarocks (no dot
> in the version number), like OpenSUSE (they seem to be the only
> distribution with a multi-version lua and that particular naming scheme
> you've chosen).

Alpine linux has multiple versions of lua, also [1].
And packages names have periods in them when lua-versions are
specified [2].

[1]: https://pkgs.alpinelinux.org/packages?name=lua5.4
     https://pkgs.alpinelinux.org/packages?name=lua5.3
     https://pkgs.alpinelinux.org/packages?name=lua5.2
     https://pkgs.alpinelinux.org/packages?name=lua5.1
[2]: https://pkgs.alpinelinux.org/packages?name=lua*


Among cygwin packages, guile packages have dots in their package names.

[3]: https://cygwin.com/packages/summary/guile3.0-src.html
     https://cygwin.com/packages/summary/guile2.2-src.html
     https://cygwin.com/packages/summary/guile2.0-src.html
     https://cygwin.com/packages/summary/guile1.8-src.html


And, I'm wondering about no-dot-in-the-version scheme...  What should we
do if its version comes to 5.10 or higher (just a hypothecical example).
It will be lua510-* without dots, but I would feel uneasy for it (just
in my opinion).


> A different question is if you really want to package this particular
> feature.  Just like all the other "package managers" that come with a
> specific language or interpreter I'd expect this one to need (maybe
> extensive) modifications to work correctly on Cygwin, especially if it
> ends up building dynamic objects.

Does it mean that we should have a way to rebase such dynamic objects
automatically?


> That's one reason I discourage the
> use of CPAN on Cygwin, since folks tend to shoot themself into the foot
> more often than not by using it.

All right. Maybe, I should calm myself down.

I will try simply to build subpackges for lua-5.4.2 (test), for the time
being.


Regards,

Lem

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Achim Gratz]

Lemures Lemniscati via Cygwin-apps writes:
> Alpine linux has multiple versions of lua, also [1].
> And packages names have periods in them when lua-versions are
> specified [2].

I still consider Alpine a special snowflake despite their gains in
container environments since they tend to have their own package splits.

> Among cygwin packages, guile packages have dots in their package names.

Nobody said things were consistent.

> And, I'm wondering about no-dot-in-the-version scheme...  What should we
> do if its version comes to 5.10 or higher (just a hypothecical example).
> It will be lua510-* without dots, but I would feel uneasy for it (just
> in my opinion).

We will cross that bridge when we get there.

> Does it mean that we should have a way to rebase such dynamic objects
> automatically?

Well, the first step is to make sure that packaged and locally installed
stuff stays separate (for Perl this is the distinction between vendor
and site distributions) and set up a sensible precedence order.  Next is
that users might not have admin rights, so there's a separation between
local system and local user to consider (Perl: local::lib).  Once you
have that sorted then yes, you need to think about when and how to do
the rebase of any dynamic objects you are going to produce.  For Perl I
managed to insert an automatic ephemeral rebase, but only for i686 and
packages built with ExtUtils::MakeMaker (so that build tests can
actually work without having to do an extra step).  The local
installations should be taken care of via the autorebase facilities,
although that requires cooperation from the system admin for user
installations.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA

[Lemures Lemniscati]

On Sun, 17 Jan 2021 07:59:14 +0100, Achim Gratz
> Lemures Lemniscati via Cygwin-apps writes:
> > Does it mean that we should have a way to rebase such dynamic objects
> > automatically?
> 
> Well, the first step is to make sure that packaged and locally installed
> stuff stays separate (for Perl this is the distinction between vendor
> and site distributions) and set up a sensible precedence order.  Next is
> that users might not have admin rights, so there's a separation between
> local system and local user to consider (Perl: local::lib).  Once you
> have that sorted then yes, you need to think about when and how to do
> the rebase of any dynamic objects you are going to produce.  For Perl I
> managed to insert an automatic ephemeral rebase, but only for i686 and
> packages built with ExtUtils::MakeMaker (so that build tests can
> actually work without having to do an extra step).  The local
> installations should be taken care of via the autorebase facilities,
> although that requires cooperation from the system admin for user
> installations.
> 

Thank you for comments and advices.
I'll try it.

Regards,

Lem

Multiple version of Lua with alternatives

[Lemures Lemniscati]

Hi!

Helped by advices from Achim [1],
I prepared an experimental tree for Lua [2], as a first step.
And I'd like to request for comments about it.

* lua is forked into lua54 and lua53. It is also obsoleted by lua53.
  we can select versions by alternatives

* A new source luarocks provides lua53- and lua54-luarocks.
  They install rocks into an alternative tree /var/lib/lua-site/.

* Sources lua-crypto, lua-json, lua-ldap, lua-lfs, lua-lgi, lua-logging,
  lua-lpeg, and lua-lxp now provide lua{53,54}-* packages.

* New sources lua-ldoc, lua-luaossl, lua-lunitx, and, lua-plprovide
lua{53,54}-* packages.

* lua-luadoc is very old and obsoleted, so it is not updated.


[1]: https://sourceware.org/pipermail/cygwin-apps/2021-January/040983.html
[2]: https://cygwin-lem.github.io/lua-cygwin-packages/

Regards,
Lem

Re: Multiple version of Lua with alternatives

[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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Multiple version of Lua with alternatives

[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].

* lua53, lua53-luarocks,
* lua54, lua54-luarocks.

[1]: https://cygwin-lem.github.io/lua-cygwin-packages/

And, here is a sample script to see whether luarocks works or not:

--------
luarocks-5.4 install argparse \
&& luarocks-5.4 list \
&& lua5.4 -e 'require("argparse")' && echo OK \
&& luarocks-5.4 remove argparse

luarocks-5.3 install argparse \
&& luarocks-5.3 list \
&& lua5.3 -e 'require("argparse")' && echo OK \
&& luarocks-5.3 remove argparse
--------

Regards,

Lem

Multiple versions of Lua with alternatives

[Lemures Lemniscati]

Hi!

We have lua5.1 packages [1] besides lua packages [2] in the current
Cygwin distribution, although we have no lua 5.1 module packages.

So I've added simply lua51 (obsoleting lua5.1) and no lua51-* module
to the tree [3], which I'm proposing.

[1]: https://www.cygwin.com/packages/summary/lua5.1-src.html
[2]: https://www.cygwin.com/packages/summary/lua-src.html
[3]: https://cygwin-lem.github.io/lua-cygwin-packages/

Regards,

Lem

Re: Multiple version of Lua with alternatives

[Lemures Lemniscati]

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.

Regards,
Lem

Re: Multiple version of Lua with alternatives

[Marco Atzeri]

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.
> 
> Regards,
> Lem
> 

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

Re: Multiple version of Lua with alternatives

[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/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.]

Re: Multiple version of Lua with alternatives

[Lemures Lemniscati]

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/

Regards,

Lem

Re: Multiple version of Lua with alternatives

[Brian Inglis]

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.]

Re: Multiple version of Lua with alternatives

[Lemures Lemniscati]

On Wed, 24 Feb 2021 09:38:33 -0700, Brian Inglis
> 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/

Thank you.

Their places for luarocks package itself seem to be almost default
with prefix /usr.


I've tested luarocks on fedora/opensuse/debian/ubuntu to find out places
in which luarocks install rocks and libraries [1].

[1]: https://gitlab.com/test.cases/luarocks-test/-/pipelines/262667066


fedora:  using /usr tree
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115707
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115708
  /usr/bin/
  /usr/lib64/luarocks/rocks-5.4/
  /usr/lib/lua/5.4/
  /usr/share/lua/5.4/

opensuse:  using /usr tree
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115709
  /usr/bin/
  /usr/lib64/lua/5.3/
  /usr/lib/luarocks/rocks-5.3/
  /usr/share/lua/5.3/

debian/ubuntu:  using /usr/local tree
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115705
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115706
 https://gitlab.com/test.cases/luarocks-test/-/jobs/1060115710
  /usr/local/bin/
  /usr/local/lib/luarocks/rocks/
  /usr/local/lib/lua/5.1/
  /usr/local/share/lua/5.1/

Lem

Re: Multiple version of Lua with alternatives

[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.

>> > 2) luarocks_tree=/usr/lib/lua/luarocks
>> > 3) luarocks_tree=/usr/libexec/lua/luarocks

Both of these are for architecture specific components.  I fkeep
forgetting the exact definition of libexec in FHS, but I think it's for
components that users would not invoke directly (if it exists at all).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Multiple version of Lua with alternatives

[Lemures Lemniscati]

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

Re: Multiple version of Lua with alternatives

[Lemures Lemniscati]

On Sun, 28 Feb 2021 18:34:36 +0900, Lemures Lemniscati
> On Sat, 27 Feb 2021 13:32:37 +0100, Achim Gratz
> > >> > 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.
> 
> (B) using mixed tree prefixes and removing tautological directories

I've reconfigured with these settings [1]:

* luarocks tree: /usr

[maybe architecture-specific components]
* rocks: /usr/lib/lua/luarocks/rocks-${LUA_VERSION}
* manifest: /usr/lib/lua/luarocks/rocks-${LUA_VERSION}/manifest
* deploy_bin_dir: /usr/lib/lua/luarocks/bin
* deploy_lib_dir: /usr/lib/lua/luarocks/${LUA_VERSION}

[architecture-independent components]
* deploy_lua_dir: /usr/share/lua/luarocks/${LUA_VERSION}

[1]: https://cygwin-lem.github.io/lua-cygwin-packages/

Regards,
Lem