Correct useage of the /var directory #281
Labels
No labels
bug
duplicate
enhancement
help wanted
in progress...
information
invalid
not enough info
priority high
priority low
priority normal
question
request
research
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Techwizz/pvpgn-server#281
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Directory /var/pvpgn is illegal for the most of Unix system
/var/log/pvpgn
/var/lib/pvpgn
/var/games/pvpgn must be used
/var/pvpgn is not used. How did you try to install it?
Ok, /usr/local/var/pvpgn . If someone need to disribute a binary package it's the most strange path for the package installation directory. As for sources installation - it won't be worse.
You are correct, it is not by FHS. Can you write a full list of path changes that would have to be done?
As I noticed during package maintaining:
/var/lib - for main /var
/var/games - for gamesaves
/var/log - for any logs
/var/run - for pid files
bin and sbin directory must be inside /usr
I don't know if I am completely correct, full list I'll try to provide ASAP
Shouldn't be hard for Ubuntu to specify the correct path (more precisely the ways which are already familiar)
but, I see no reason to use a catalog of games.
As for /var/games it may not be used at all (it is only two/three temp files there, that can be modified in bnetd.conf and hasn't sources), but as we said about standarts, it must be.
What does you mean 'for Ubuntu'. Ubuntu is not the only *nix OS
@DragonZX Any progress on this?
Still research with other path issues. I've no time this weeks.
How about we simply install to /opt/pvpgn or /var/lib/pvpgn? Postgresql installs to a single directory and has config, logs and data all in one place for example. The advantage of this approach is that you can simply copy the whole folder and move server somewhere else and it is also easier to navigate.
@DragonZX does this seem reasonable?
@cen1 In my opinion, it may be compiled to the opt directory anyway. All logs MUST be in the /var/log directory, due to logrotate functions. Also as pid must be in /var/run to use it with daemons
I decided to use
/usr/local
since it is the correct path for local software installations. I'll add/var/run
and then prepare a pull request to test it.I had to add additional cmake flag for custom paths because /var/log and /var/run are static and can't be prefixed with EXEC_INSTALL_PREFIX. For custom paths, all files preside under that custom root.
Without changing it, default is /usr/local
I need a review before merge request: https://github.com/cen1/pvpgn-server/tree/installpath
I'll check ASAP, maybe during this weekend
FHS non-compliance is a serious issue. Everything is installed to wrong place and this is an obstacle to updating the official Debian package. CMAKE makes customisation of installation directories relatively easy:
but pvpgn hard-codes locations in
cmake/Modules/DefineInstallationPaths.cmake
which makes them needlessly difficult to override. I've used the following patch:Another problem is that i18n files are installed to
/etc/pvpgn
which is wrong.i18n
should be installed to/usr/share/pvpgn
but I'm not sure what is the best way to modifyconf/i18n/CMakeLists.txt
to accomplish that...Be aware that this repository is PvPGN PRO, a fork of the official PvPGN.
Related: #425
Looks like a continuation to me. Original project is dormant with no activity in SourceForge project for about a decade.
The original PvPGN web site on berlios.de refers to PvPGN PRO (which points to this very project).
As far as I can say, no development of this software is done elsewhere...
As this project has had no new commits for a long time, I'll try to review it again. 4 years ago it's finished by placing all the files to the /opt directory and reconfiguring logrotate for it. I think it's no need to provide compatibility with the old package, however, we need to beautify its structure.