0003245: Add /usr/share/games/doom to default configuration IWAD/PWAD paths on GNU/Linux systems

Notes
(0018225) Filystea (reporter) 2017-09-03 07:36	Would be better to simply move init files in .doomseeker to sub directory and leave maps in .doomseeker or in it's maps subdir. And: " /usr/share/games/doom" Fine but not default map download. Not everyone keeps everything on same partition. I expect to download maps to my home.

(0018227) WubTheCaptain (reporter) 2017-09-03 18:34 edited on: 2017-09-03 18:35	The first suggestion by Filystea is covered by issue 0003233. To clarify, the default Wadseeker path is not in scope of this suggestion as pointed out by Filystea. If it was to be considered, /usr/share/games/doom is owned by root:root and that makes it impractical for a default user-specific Wadseeker path. More likely anything in /usr/share/games/doom is installed through Debian packages (dpkg/apt).

(0018249) Zalewa (developer) 2017-09-09 18:49	Do you think we should add this directory regardless if it exists or should we first check if it exists? The first approach adds a standard directory to the config with expectation that the user will eventually put something there (by package installation). The other approach keeps the list clean but user will have to add the directory manually once the relevant packages are installed. I would rather have user have complete control over their paths so hardcoding anything that cannot be disabled is out of the question. Moreover: do we also have to add /usr/local/share/games/doom? Moreover, also: do we need to add extra distro check to see if we're on a Debian-like system and only then add the directory, or can we expect that this path will be valid for all Linux distros?

(0018255) WubTheCaptain (reporter) 2017-09-10 12:58	Zalewa: Good questions. It seems the Doomseeker configuration is user-specific. That is, each user has their own Doomseeker configuration with IWAD/PWAD paths somewhere in their $HOME directory. There is no global configuration file under /etc directory, so complete control shouldn't be an issue. Debian's policy (version 4.1.0.0, section 10.7.3) mandates "local changes to be preserved during a package upgrade". I thought about "have the engine plugin add it with enable/disable options if installed", but this is a bit tricky and may not be a good idea. Furthermore, the previously mentioned section says not everything needs to be configured, "only those necessary to get the package running"; ideally without sysadmin (or user) interaction. Section 10.7.5 hints "programs that require dotfiles" in $HOME directory "in order to operate sensibly are a bad thing". It may not be a bad thing if the dotfile is created automatically, however. Requiring the user to change their dotfile configuration (either directly or via the graphical interface) to operate sensibly is of course "a bad thing". I'd probably prefer consistent behavior, where it's either included and enabled by default or isn't. The user itself would probably place to $HOME/.local/share/games/doom, and the sysadmin places to /usr/local/share/games/doom (for all the users). Packages installed by the sysadmin (from the operating system's repositories) go to /usr/share/games/doom. Freedoom's Makefile installs to $(target)$(waddir), where waddir is /share/games/doom by default and target is $(DESTDIR)$(prefix). Prefix is commonly /usr, such as in Arch GNU/Linux AUR repositories. You should be able to expect the path to be valid for all GNU/Linux distributions (at least those that implement the Filesystem Hierarchy Standard to a degree). These are some suggestions.

(0018258) Zalewa (developer) 2017-09-10 13:26	Quote from "Zalewa" I would rather have user have complete control over their paths so hardcoding anything that cannot be disabled is out of the question. Foolish me. I forgot we already do this and so far it hasn't caused any problems. Look:'https://bitbucket.org/Doomseeker/doomseeker/src/425fdc3f5ee449ae89ad3bfe0d8cb0e35030daa8/src/core/pathfinder/pathfinder.cpp?at=default&fileviewer=file-view-default#pathfinder.cpp-114 [^]'

(0018260) Zalewa (developer) 2017-09-10 17:38	Okay, this should do it:'https://bitbucket.org/Doomseeker/doomseeker/commits/d00d1352a20bbb5df7ffbc2fe6c5ab3677380037 [^]'

(0018262) WubTheCaptain (reporter) 2017-09-10 21:19	I tested the commit you've linked. It's working okay. User-configured IWAD/PWAD paths take presedence over over the hardcoded ones and /usr/local takes presedence over /usr. Good things. Works for Chocolate Doom, Zandronum, Odamex, but not SRB2 and Turok 2. All as intended. Joining the server works too. Default IWAD isn't configured in server browser for Chocolate Doom or Zandronum. Whether this is a good or bad thing, I'm not sure. Out of scope for this ticket, anyway. Not sure what else there is to say.

(0018263) WubTheCaptain (reporter) 2017-09-10 21:21	The search path behavior should obviously be documented in manual pages: 0003247.

(0018276) Zalewa (developer) 2017-09-11 18:49	Quote from "WubTheCaptain" Default IWAD isn't configured in server browser for Chocolate Doom or Zandronum. Whether this is a good or bad thing, I'm not sure. Out of scope for this ticket, anyway. Thanks for bringing this to my attention. It was pretty serious.

(0018283) WubTheCaptain (reporter) 2017-09-12 02:04	Derp, I meant to say the "Create Game" window doesn't have a default IWAD path set for the selected engine in fresh configurations and that may be a good or bad thing. That is (was?) a seperate issue anyway, out of scope for this ticket. If that needs testing, a new ticket should be created. What exactly needs testing in the latest commit you linked? Repeat the testing process?

(0018286) WubTheCaptain (reporter) 2017-09-12 02:51 edited on: 2017-09-12 02:59	Sorry for the lack of clarification: I only previously tested /usr/share/games/doom and /usr/local/share/games/doom with Freedoom and Doom 2 WADs. I've never played SRB2 or Turok 2, so I don't know how those work. I see no practical difference in scope of this ticket while testing the latest build with a fresh configuration (removed all *.ini files). Out of scope: I have Freedoom installed via Debian packages (apt) and Doom 2 in $HOME/.local/share/games/doom. The "Create Game" option now defaulted the engine IWAD for Doom things to /home/wub/.local/share/games/doom/DOOM.WAD, once I added /home/wub/.local/share/games/doom to the IWAD/PWAD paths before opening "Create Game". If I did not add the IWAD/PWAD path first, it defaulted the IWAD to /usr/share/games/doom/freedoom.wad. My /usr/local/share/games/doom was empty. Prioritization also seems to work correctly: User-configured paths /usr/local/share/games/doom /usr/share/games/doom I think it's working as you wanted.

(0018290) Zalewa (developer) 2017-09-12 17:51	There are several places where Doomseeker needs to find WADs (or any game files, so .pk3, .deh, .7z, .zip also count). WADs must be found case-insensitively. On Windows this is easy, because Windows filesystem is case-insensitive. On Linux DOOM2.WAD, doom2.wad or DoOm2.WaD are separate files but Doomseeker shouldn't care and treat them equally. This is documented here:'http://doomseeker.drdteam.org/docs/doomseeker_1.1/classPathFinder.php [^]' As for the places where WADs are being found: - Any place where IWAD is to be picked from a drop-down list, so this should apply to the Create Game box and the box that pops up when you try to join a Chocolate Doom server. This is for convenience purposes as we also allow to specify the path to IWAD by hand. - Any place where WADs are being found without having to specify their paths by hand, so: -- when joining a server or obtaining its join command line, -- when playing back a demo, -- when trying to download missing files from server list context menu, -- when trying to display paths to IWAD or WADs in server list tooltips, -- when trying to find Freedoom in "Install Freedoom" dialog box.

(0018391) WubTheCaptain (reporter) 2017-09-25 23:40	Do we want to consider the INSTALL_PREFIX for this one too?

(0018393) Blzut3 (administrator) 2017-09-26 00:43	I don't think these paths should be related to the install prefix as we don't control the game data packager (which is ultimately where these paths come from). We can't know the correct prefix for the game data packager but /usr and /usr/local are reasonable guesses.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2017-09-01 16:29	WubTheCaptain	New Issue
2017-09-01 16:32	Zalewa	Relationship added	child of 0003246
2017-09-03 07:36	Filystea	Note Added: 0018225
2017-09-03 18:34	WubTheCaptain	Note Added: 0018227
2017-09-03 18:35	WubTheCaptain	Note Edited: 0018227	View Revisions
2017-09-09 18:49	Zalewa	Note Added: 0018249
2017-09-10 12:58	WubTheCaptain	Note Added: 0018255
2017-09-10 13:20	Zalewa	Assigned To	=> Zalewa
2017-09-10 13:20	Zalewa	Status	new => assigned
2017-09-10 13:26	Zalewa	Note Added: 0018258
2017-09-10 17:38	Zalewa	Note Added: 0018260
2017-09-10 17:38	Zalewa	Status	assigned => needs testing
2017-09-10 21:19	WubTheCaptain	Note Added: 0018262
2017-09-10 21:21	WubTheCaptain	Note Added: 0018263
2017-09-11 18:49	Zalewa	Note Added: 0018276
2017-09-12 02:04	WubTheCaptain	Note Added: 0018283
2017-09-12 02:51	WubTheCaptain	Note Added: 0018286
2017-09-12 02:57	WubTheCaptain	Note Edited: 0018286	View Revisions
2017-09-12 02:59	WubTheCaptain	Note Edited: 0018286	View Revisions
2017-09-12 17:51	Zalewa	Note Added: 0018290
2017-09-13 16:45	Zalewa	Status	needs testing => resolved
2017-09-13 16:45	Zalewa	Fixed in Version	=> 1.2
2017-09-13 16:45	Zalewa	Resolution	open => fixed
2017-09-25 23:40	WubTheCaptain	Note Added: 0018391
2017-09-25 23:40	WubTheCaptain	Status	resolved => feedback
2017-09-25 23:40	WubTheCaptain	Resolution	fixed => reopened
2017-09-25 23:44	WubTheCaptain	Note Added: 0018392
2017-09-25 23:44	WubTheCaptain	Status	feedback => assigned
2017-09-25 23:53	WubTheCaptain	Note Deleted: 0018392
2017-09-26 00:43	Blzut3	Note Added: 0018393
2017-09-26 12:35	WubTheCaptain	Status	assigned => resolved
2017-09-26 12:35	WubTheCaptain	Resolution	reopened => fixed
2018-09-27 03:16	WubTheCaptain	Target Version	=> 1.2
2018-10-08 08:39	WubTheCaptain	Severity	minor => tweak
2018-10-27 22:54	WubTheCaptain	Status	resolved => closed