This topic contains 8 replies, has 0 voices, and was last updated by  imported_gcamp 14 years ago.

  • Author
  • #2411


    It’s about time you fixed up the directory structure under linux. 99% of all programs out there use the standard /usr/local/share /usr/local/bin and /usr/local/lib directories for the program to be installed in (and maybe some more). You however seem to have some sort of pseudo standard in where you just have the binary and other data files branching from its own directory!! This is not acceptible, please stop creating your own standards. In windows I can understand why you would have it this way, but not linux folks.

    And also under ./configure when I parse stuff like –datadir, –libexecdir and –bindir, they don’t function as they should! Instead I find the binary and other data in the same directory structure. About the only thing that makes a difference is –prefix.

    Please fix this at least in your next release.

    Btw, great game! This is the only flaw I’ve noticed.



    Since you clearly have both great knowledge and much time on your hands, why not download the latest CVS, fix the percieved problem and send in a patch?

    What’s that? You just wrote in to complain? Never mind.



    Relax man, I can see that this is not the standard on one of the supported OSs, and for that I am deeply sorry. But does it really cause such a problem?

    Perhaps if I understood the issues and obvious grief it causes I would raise the priority of fixing it!


    The reason for this is because most linux distributions have directory standards (eg: some prefer /usr/local, whilst others just prefer /usr) and these cannot be implemented when commands like ./configure –datadir=/blahblah don’t work.


    chomsky, clam down you little bitch.

    Hi gcamp!

    No need to apologise there, the great game you have produced does this for you 🙂

    The reason I am pushing for a standard directory structure under linux/unix is that it would make it infinately easier to package this game and distribute to people who are using a particular distribution. So far only –prefix manages to change the way the game is installed.

    For instance if I did:
    ./configure –prefix=/opt

    I would get a directory structure like this…
    With the binary located under /opt/scorched3d/scorched3d

    Under most programs a prefix of /opt would have a more standard directory structure like… (we’ll use scorched3d as an example)
    /opt/bin/scorched3d (binary location)
    /opt/share/scorched3d/ (data location)
    /opt/docs/scorched3d/ (documentation location)

    logs would usually be placed in the home directory of whoever is playing the game. For instance:
    $HOME/.scorched3d/logs/ (logs directory)

    The configuration file would also be placed in a similar way (for example):

    All this helps keep a consistent approach and would be greatly appreciated if you could implement this. Also, sorry about my uninformative ramblings in the first post. I hope this will be more helpful.



    And if you would try to put it in the PATH, it would be a pain without altering the path… You would have to use /bin/scorched3d and /bin/scorched3d/blahblah as install dir…

    Personaly i install all GUI progs. in /usr/local/(game)/progname when i use the source, but else I always use /usr for RPMS (as they an be easyly uninstalled, even if spread throughout the whole directory structure…)



    While I realize that the linux port is still evolving, I would like to point out that having all of the files world writable is a serious security concern. I note that it is set up this way in the RedHat 9 binary RPM.

    Just wanted to bring that issue to your attention.



    Guppie, if you are running a multiuser system, then yes, there is a remote possibility of one of your users corrupting your files. If this is the case, and you are worried about your users’ intentions, then I would suggest you investigate ‘chmod’. If on the other hand you are running a single user system then your principal security precaution should be running the server from a non-root account. The mere fact that a file is world writable (or executable or readable) is not inherently dangerous; it depends upon your environment.



    well, if an executable or lib is left world-writable, THAT IS A HUGE SECURITY RISC. then anyone could write some shit to it, and it would then be run the next time of execution in place of the real code…



    @kyrsjo wrote:

    well, if an executable or lib is left world-writable, THAT IS A HUGE SECURITY RISC. then anyone could write some shit to it, and it would then be run the next time of execution in place of the real code…

    But only people that have already access to the computer and an account anyway. I would not give people that cause a huge risk an account on my personal machine. I can also think of much worse things I could do given an account and access.

    Not a big deal I think, but yes, I will change it.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.