Bug 143284 - starfigher binary placed in /usr/share/games instead of /usr/bin
Summary: starfigher binary placed in /usr/share/games instead of /usr/bin
Alias: None
Product: Fedora
Classification: Fedora
Component: starfighter
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-18 01:41 UTC by Jef Spaleta
Modified: 2018-12-28 11:43 UTC (History)
0 users

Clone Of:
Last Closed: 2005-01-05 18:42:48 UTC

Attachments (Terms of Use)

Description Jef Spaleta 2004-12-18 01:41:58 UTC
Description of problem:
starfighter binary is in /usr/share/games/ which is outside the
default path for fedora core.  I expected the binary to be in /usr/bin/

Version-Release number of selected component (if applicable):

Comment 1 Matthias Saou 2005-01-05 18:42:48 UTC
It is not in /usr/share/games, but in /usr/games/, and this is
actually correct, and the default behavior of starfighter's
installation, so I don't really see any point in changing it, as there
is no advantage in having a graphical game in one's $PATH.

See the FHS, which mentions this optional /usr/games (which is
present, although empty, by default on FC and owned by the filesystem
package) :

"Games and educational binaries (optional)"

Closing as WONTFIX, unless someone has a really strong objection and
valid point in having this in /usr/bin.

Comment 2 Jef Spaleta 2005-01-05 18:56:27 UTC
I'm just looking for consistent behavior inside of extras and
consistent behavior across the Core/Pre-Extras boundary.   

I don't know of any Core games or any pre-existing fedora.us game
packages that place their binary executables outside the default
excutable path. So while the FHS optionally allows it, I'm not sure if
the distribution policy for extras is narrowerly defined.    

Comment 3 Matthias Saou 2005-01-05 20:11:31 UTC
I think I recall fortune being in /usr/games at the time is was still
part of Red Hat Linux :-) And it was much more of a problem since as a
console program, having it in the $PATH would have made things easier.

Comment 4 Ville Skyttä 2005-02-02 22:55:20 UTC

IMO the binary or a symlink to it in $PATH would meet the POLA better
than not having it there.

Consistency: just look through other graphical stuff in the menus; how
many of those executables are not in $PATH?

I see no reason to force users to use the menus or GUI launcher icons
or to force them to remember the full path to the app.  Having it in
$PATH hurts no-one, and not having it there does hurt, if not the
majority, lots of users anyway.

Comment 5 Matthias Saou 2005-02-02 23:12:27 UTC
I really don't get what the fuss is about. It's not like I'm putting
the binary there on purpose, it defaults that way, and I simply want
to keep things simple and always as close to upstream as possible if
there's no strong reason to change things.
The users "hurt" are those wanting to run the game from the console
(very few "desktop users", I'd imagine)... but the thing is, those
same users definitely know how to run "rpm -ql starfighter | grep bin" ;-)

Comment 6 David Utidjian 2005-02-03 03:36:00 UTC
I just checked my FC# and /usr/games/ has /usr/games/Maelstrom/ in it.
The contents of that folder appear to be only libs... stuff that might
normally go into /usr/lib/games/Maelstrom/ (if it existed). In
/usr/lib/games/ I have /usr/lib/games/xpat/ which I built locally. The
binary for Maelstrom is in /usr/bin/ as are all the other games I have
installed via the ISOs for FC3.

I, personally, could care less where they go... as long as it is
consistent. /usr/bin/ is fine with me as is /usr/games/. If games are
going to be installed in /usr/games/ then I think *all* gmaes should
be installed there.

Note You need to log in before you can comment on or make changes to this bug.