launcher expects terps binaries in a non-standard location

[GoogleCodeExporter]

Gargoyle launcher script looks for terps binaries in some risky places.
first, it expects the binaries in /usr/share/bin, but usr/share hierarchy
(per FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
)
is reserved for architecture-independent files. then, launcher checks it's
current directory. this may be necessary for self-contained,
single-directory Gargoyle installations, but assuming that it's installed
system-wide, this possibly results in filename conflicts between terps
binaries and non-gargoyle binaries. frotz and git being the most obvious.
so there's really no safe place to install the terps to. it's of little
consequence in case of a manual, local installation, but will possibly
hinder packaging and redistribution on all FHS-compliant systems that'd
want to include Gargoyle in their software distribution system. eg. most
Linux distributions. a quick fix constitutes changing the path to some
subdirectory of /usr/bin. on a side note, I love this project, it's great
seeing it move forward so nicely. :-)

Original issue reported on code.google.com by lordofch...@gmail.com on 24 Jun 2009 at 2:48

[GoogleCodeExporter]

I encountered the same issues when writing a Gentoo ebuild for garglk and dealt 
with
it this way:
 1. the main script (gargoyle) goes into /usr/bin
 2. the interpreter binaries go into /usr/libexec/gargoyle
 3. symlinks to interpreter binaries go in /usr/bin (e.g. /usr/bin/gargoyle-git =>
/usr/libexec/gargoyle/git)
I think no-one disputes (1). The rationale for (2) is that (as you said)
architecture-dependent binaries don't belong in /usr/share, and since 
applications
shouldn't create subdirecties in /usr/bin, a subdirectory in /usr/lib or 
/usr/libexec
is the sensible option.

The file hierarchy standard only mentions /usr/lib but /usr/libexec is widely 
used
(and present on all Linux distributions that I'm aware of) to place executable
binaries (instead of just loadable libraries). Either /usr/libexec or /usr/lib 
would
be defensible.

The rationale for (3) is to allow users to run a specific interpreter without 
having
to specify an absolute path; the gargoyle-prefix is useful to prevent 
collisions with
other tools. I guess this is an optional feature.

I'm not sure if the installation paths are  a big problem in practice, since 
most
package builders probably override the installation paths anyway, but having to
modify the launcher script to get it to search in /usr/libexec is a bit ugly.

Original comment by znxfire...@gmail.com on 24 Jun 2009 at 1:20

[GoogleCodeExporter]

quite. though /usr/libexec is not HFS-compliant as well, and some distros will 
use it
very reluctantly. eg. Debian and it's derivatives. /usr/lib subdir can be used, 
but
(per FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA)
 it
should only include files "that are not intended to be executed directly by 
users or
shell scripts". so it's an acceptable, although sub-optimal option as well. 
another
option would be using /usr/bin for all binaries, but that would require 
renaming all
terps binaries to reflect their association with Gargoyle, to prevent conflicts.
perhaps that would be best, since this approach results in considerably less
potential conflicts, as well as simplified launcher script.

Original comment by lordofch...@gmail.com on 24 Jun 2009 at 6:41

[GoogleCodeExporter]

This is vestigial behavior from a recommendation a few months back.  I should 
scrap
the check for /usr/share/gargoyle/bin altogether, so it doesn't carry the 
weight of a
suggestion.

The expected package behavior (and also for instance when running "jam install
SYSTEM=1" for a local system-wide install) is this:

1) Binaries are placed in /usr/libexec/gargoyle
2) The launcher is also placed in /usr/libexec/gargoyle
3) The garglk library is placed in /usr/lib/gargoyle
4) A "gargoyle" symlink is created in /usr/bin, linked to 
/usr/libexec/gargoyle/gargoyle.
5) garglk.ini is copied to /etc/garglk.ini
6) A file containing a reference to /usr/lib/gargoyle is added to 
/etc/ld.so.conf.d

This way the launcher script is in the path, but the individual terps (with 
their
various name clashes) are not.  When the launcher runs, it is actually invoked 
from
the /usr/libexec/gargoyle directory, where the rest of the terps are located.

It shouldn't be necessary to modify the script in this scenario - the 
/usr/share bit
does nothing.

The paths above are not hardcoded (unless you invoke jam with the SYSTEM=1 
variable
set) so you can override them in a package that builds from source by setting 
_BINDIR
(for terps), _APPDIR (for launcher), and _LIBDIR (for library) correctly.

Original comment by bcressey@gmail.com on 24 Jun 2009 at 6:45

• Changed state: Accepted
• Added labels: Build, OpSys-Linux

[GoogleCodeExporter]

libexec may not be acceptable on a given distribution, but it seems like most 
offer
or suggest a similar place to store required files in such a way as to avoid 
name
clashes.

I'm not sure that there's much to be done about it from the perspective of the
project as a whole.  The compile variables seem to offer the right amount of
flexibility, and the individual distribution standards will govern what those 
values
need to be.

I am certainly open to suggestions - let me know if there's something more I 
can do
at the project level to make your lives easier.

Original comment by bcressey@gmail.com on 24 Jun 2009 at 7:03

[GoogleCodeExporter]

yea, scrapping the /usr/share/gargoyle/bin check would certainly be a step 
forward.
it's currently misleading and promotes bad packaging practices. aside from that,
please consider renaming the terps binaries. this, as I see it, would solve the
problem altogether, allowing them to be mixed with, say, non-Gargoyle 
interpreter
binaries, in the same directory. as is, you can't run both cli frotz and 
gargoyle
frotz from the same dir. it would also remove the need for separate BIN and 
APPDIRs.
such a change is not a trivial thing, I'd imagine, but it would allow a bit more
versatility and comfort of usage and packaging. however, it's not a pressing 
matter,
and there are surely some downsides to such an approach.

Original comment by lordofch...@gmail.com on 24 Jun 2009 at 9:59

[GoogleCodeExporter]

thanks. guess this can be marked as fixed, since renaming the terps is a whole
different beast, if it's feasible at all.

Original comment by lordofch...@gmail.com on 25 Jun 2009 at 6:13

[GoogleCodeExporter]

Original comment by bcressey@gmail.com on 25 Jun 2009 at 6:29

• Changed state: Fixed