public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: Multiple version of Lua with alternatives
Date: Sat, 27 Feb 2021 13:32:37 +0100	[thread overview]
Message-ID: <878s79k7x6.fsf@Rainer.invalid> (raw)
In-Reply-To: <20210227171327.39AC.50F79699@gmail.com> (Lemures Lemniscati via Cygwin-apps's message of "Sat, 27 Feb 2021 17:13:29 +0900")

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

  reply	other threads:[~2021-02-27 12:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 10:06 [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA Lemures Lemniscati
2021-01-15 20:02 ` Achim Gratz
2021-01-15 23:16   ` Lemures Lemniscati
2021-01-16  6:50     ` ASSI
2021-01-17  1:20       ` Lemures Lemniscati
2021-01-17  6:59         ` Achim Gratz
2021-01-18  9:20           ` Lemures Lemniscati
2021-02-15 15:12           ` Multiple version of Lua with alternatives Lemures Lemniscati
2021-02-20  7:40             ` Achim Gratz
2021-02-20 10:15               ` Lemures Lemniscati
2021-02-22 22:14                 ` Multiple versions " Lemures Lemniscati
2021-02-24  4:18                 ` Multiple version " Lemures Lemniscati
2021-02-24  5:20                   ` Marco Atzeri
2021-02-24  6:53                     ` Brian Inglis
2021-02-24 11:03                       ` Lemures Lemniscati
2021-02-24 16:38                         ` Brian Inglis
2021-02-27  8:13                           ` Lemures Lemniscati
2021-02-27 12:32                             ` Achim Gratz [this message]
2021-02-28  9:34                               ` Lemures Lemniscati
2021-03-01 11:26                                 ` Lemures Lemniscati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878s79k7x6.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).