[Linux, Somewhere after r1316] Cannot find zdoom.pk3

[Marisa the Magician]

So... I built latest git master after almost a month, and suddenly ZDoom seems to be unable to find its own .pk3 file. I've checked with strace, and it seems it doesn't even look in /usr/share/games/zdoom as it has always done. Settings aren't even loaded to read the iwad and file search directories.

All there is is two calls to stat, one for "./zdoom.pk3" and one for "zdoom.pk3". I've also noticed it seems to look for a folder named "zdoom" in the current working directory, but making a folder with that name just makes the "./zdoom.pk3" become an absolute path (i.e.: "/home/whatever/zdoom.pk3").

I'm really confused about where the problem is because there's just too many commits to look into.

[randi]

That's what git bisect is for. You know a good version, and you know a bad version, so you can use it to quickly find the commit where it went bad.

[Marisa the Magician]

I had to skip lots of commits since they failed to compile altogether, so... this ended up happening.

Code: Select all

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
3114a26bc8aa7984b92db3da9ac311cd8e7b0567
3241b1d3db2d9ce75f303bbf15af3eb3cb79b12b
258822ef3bab753113eec96c6196f0fd2dc69a7b
cac634567bb368d3b19e797175443574ece1dbb4
b300cfaf62e60aef1b48548c406f46bbb4edaecd
dfda74ffe3496997caef6732fd302bb52eb683ac
a013703e1ce8a41dafb148c02b2ee3d3b20673b2
c36222d2ef6c61e5d1693130d6311ff90df41ac6
62d036a63e12cdafb74ff617a5bd58444892284e
7d2ab461d9820c5f42d1d9ddaad564bcab1789c6
4971e7def1462461579ae30750c679365536e564
We cannot bisect more!

Edit because double post

Well, after checking each of the commits, it seems the problem lies here.

Is it just me or was this made with only Windows taken into account, where the pk3 and the binary are in the same folder?

[Edward-san]

Where do you put the zdoom program? I always have zdoom and zdoom.pk3 in the same folder, considering it's the default when I build with cmake ...

[Marisa the Magician]

zdoom goes in /usr/bin/, and the pk3 goes in /usr/share/games/zdoom/. That's how it has always been in Arch, dunno about other distros.

[Blzut3]

Fixed by separating autoload initialization from the rest of the ini.

[Graf Zahl]

Sigh...

What is it with Linux and this insane data organization where a single app is spread out all over the file system...

[Caligari87]

Apparently to veteran Linux users, it's no different than dealing with the Windows Registry and programs installing stuff to the Windows/ProgramFiles/User/AppData/Whatever directories. I love Linux, but that is one thing that bugs me; I do usually prefer to have everything portable in a single directory.

[Graf Zahl]

User/AppData/Whatever folders are fine - as long as they are used properly. What should go in there is config files and other stuff that gets WRITTEN by the app while it runs - internal stuff to AppData and user visible content to Documents. What I don't understand what zdoom.pk3 has to do there. It's part of the binary package, directly tied to the executable it comes with. So by all sane reasoning it should be in the same place.

[Edward-san]

Yeah, I believe these maintainers are doing it wrong. drdteam debian packages put the executable, the pk3 and the libraries in one place (/opt/zdoom for zdoom, /usr/games/zandronum for zandronum). Then, in /usr/bin it's put a simple bash script called, not casually, 'zdoom', which calls the right program in the right place.

[VoidMage]

What I don't understand what zdoom.pk3 has to do there. It's part of the binary package, directly tied to the executable it comes with. So by all sane reasoning it should be in the same place.

So, basically, the argument is "they're doing it wrong, cause they're doing it in a different way than one I'm used to".

While FHS is somewhat a blowback from the far past, where Unix was tied to specific hardware (you can google the bikesheding about "/usr separation" for some details), it has some its upsides.

For example, on some less than trivial setups, /usr/share can be a separate partition mounted with 'noexec' (meaning "Do not permit direct execution of any binaries on the mounted filesystem.").

Also, shell is actually useful there, so dumping noise is $PATH is quite unwelcome.

[Graf Zahl]

Yeah, I believe these maintainers are doing it wrong. drdteam debian packages put the executable, the pk3 and the libraries in one place (/opt/zdoom for zdoom, /usr/games/zandronum for zandronum). Then, in /usr/bin it's put a simple bash script called, not casually, 'zdoom', which calls the right program in the right place.

That sounds how it should be.
But may I ask why the different paths for ZDoom and Zandronum?

[Graf Zahl]

What I don't understand what zdoom.pk3 has to do there. It's part of the binary package, directly tied to the executable it comes with. So by all sane reasoning it should be in the same place.

So, basically, the argument is "they're doing it wrong, cause they're doing it in a different way than one I'm used to".

No. What I'm saying is that stuff that belongs together should normally be stored together, otherwise all kinds of strange problems can creep up if more than one version of an application accesses the same data file which is actually version dependent.

[Blzut3]

But may I ask why the different paths for ZDoom and Zandronum?

Backwards compatibility. I packaged them wrong initially and then I saw Ubuntu's third party packaging standards recommending /opt/packagename. I switched ZDoom over, but switching Zandronum over is a bit of a hassle since it would break everyone's Doomseeker configuration and stuff like that.

Another recommended practice I've seen is to put a symlink in /usr/bin, so even though the binary and zdoom.pk3 are physically next to each other, additional information is potentially needed to find where ZDoom is installed. Just depends on the distro as to what is considered ideal although even "bad" packaging works.

[Graf Zahl]

Out of curiosity, how do Linux users deal with multiple versions of an application as sometimes that's necessary due to incompatibilities.
I got more than 20 ZDoom versions on my system and if they all accessed the same user data all hell would break loose.