Trenchbroom: RPM package cannot be installed on Fedora 25

[etc0de]

It appears as if it wasn't possible to install the latest RPM build on Fedora 25, at least it didn't work for me:

[root@falcon mozilla_jonas0]# dnf install ./TrenchBroom-Linux-2.0.0-Beta-2f3c498-RelWithDebInfo.x86_64.rpm 
github_git-lfs-source                           565  B/s | 1.3 kB     00:02    
github_git-lfs                                  874  B/s | 1.7 kB     00:01    
Failed to synchronize cache for repo 'pkerling-seafile', disabling.
Last metadata expiration check: 0:00:01 ago on Sat Dec 17 23:19:35 2016.
Dependencies resolved.
================================================================================
 Package           Arch         Version                Repository          Size
================================================================================
Installing:
 freeimage         x86_64       3.17.0-7.fc25          fedora             324 k
 jxrlib            x86_64       1.1-5.fc24             fedora             435 k
 libpng12          x86_64       1.2.56-2.fc24          fedora             156 k
 trenchbroom       x86_64       2.0.0-1                @commandline        70 M

Transaction Summary
================================================================================
Install  4 Packages

Total size: 71 M
Installed size: 188 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] freeimage-3.17.0-7.fc25.x86_64.rpm: Already downloaded               
[SKIPPED] libpng12-1.2.56-2.fc24.x86_64.rpm: Already downloaded                
[SKIPPED] jxrlib-1.1-5.fc24.x86_64.rpm: Already downloaded                     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /opt from install of trenchbroom-2.0.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64

Error Summary
-------------

[root@falcon mozilla_jonas0]#

[eGax]

I've never ran Fedora before, but a simple web search revealed similar issues with other 3rd party packages in recent past. It's most definitely a packaging issue with the Trenchbroom RPM that needs to be sorted out by whoever created it. From my limited understanding the spec file inside the Trenchbroom RPM used to build the package has at least one of the directories listed with 755 permissions that's owned by the file system, causing the conflict making it fail to install. The offending line is the 1st under the %files section:

_%dir %attr(0755, root, root) "/opt"_

I went ahead and installed Fedora 25 into virtualbox and following what I learned produced an installable rpm from the bugged one. I have no desire to map inside of Fedora, but it seemed to run fine for me. Fine as in made a quick quake map, put in a few models, used textures and everything loaded, looked and operating fine in the 30 minutes I putzed around. :-) So the good news is until it's fixed and you have met the dependencies you can just extract the trenchbroom folder and contents from the dep or rpm files and run trenchbroom manually or you can rebuild the package without that conflicting line yourself in only a few minutes. I'll write a little guide for you and anyone else that comes along on Fedora who might want to install TrenchBroom also.

We are going to use _rpmrebuild_ to extract the spec file to edit and then rebuild the package. We need to open a terminal any so if _rpmrebuild_ is not already installed open a terminal window and enter:

_sudo dnf install rpmrebuild_

By default rpmrebuild will use the Vim terminal text editor to edit the spec file extracted from the RPM. If you want to use any other installed text editor we can specify that before we rebuild the package by entering this in the terminal: _export EDITOR=/usr/bin/gedit_
_(Replace with whatever /pathto/favoriteditoryouprefer)_

OK, now let's do THIS! In the same terminal enter the command, options and path to the RPM that needs rebuilding:

_rpmrebuild -pe '/home/youraccountname/Downloads/TrenchBroom-Linux-2.0.0-Beta-2f3c498-RelWithDebInfo.x86_64.rpm'_
_(Change the name of the rpm if different and the directory above to where ever YOU have placed the rpm.)_

By default the spec file should load via Vim in the same terminal window. Use the down arrow key to bring down the Vim block cursor to the _%files_ section. Look for the line:

_%dir %attr(0755, root, root) "/opt"_

Put your Vim cursor on that line and delete it by tapping the [d] key twice followed by typing _:wq_ to save file and exit Vim. Now you'll see the prompt, _"Do you want to continue ? (y/N)"_ Press [y].

rpmrebuild will now build a new "valid" package that should be located in /home/youraccountname/rpmbuild/RPMS/x86_64/trenchbroom-2.0.0-1.x86_64.rpm, but it will print the location when it's finished. For me in virtualbox with an i5 intel CPU it takes just a few minutes to rebuild the rpm.

Now you can install Trenchbroom with:

_sudo dnf install /home/youraccountname/rpmbuild/RPMS/x86_64/trenchbroom-2.0.0-1.x86_64.rpm_

Enjoy!

[kduske]

Support for linux packages was added by @pnahratow -- maybe he's still around and willing to fix this?

[kduske]

@eGax thanks for investigating btw. -- good work!

[eGax]

Not a problem, trying to help where I can in return for great free software.

[ericwa]

/opt appears in the cpack configuration here:
https://github.com/kduske/TrenchBroom/blob/develop/cmake/TrenchBroomApp.cmake#L286

Possibly a cmake bug?

[pnahratow]

I have fixed this issue once before. The problem was that the rpm claims to own the /opt directory which it of course does not. This fix was just one line in the cmake file. I'll have to look through some old commits. I'm not sure where the development went since I thought we already switched to the /usr directory.

[pnahratow]

Yeah here it is #1301

[pnahratow]

So what's the status? Want me to fix this or do we finally want to move to /usr

[kduske]

From that issue report:

However since we recently moved from /opt to /usr/... this won't be an issue anymore.

That sounds like that already happened.

[pnahratow]

Its on branch Feature/1163
The exact commit is 70e5c9b

What happened to it?

[eGax]

This any use to you guys?

https://stackoverflow.com/questions/24983181/cpack-generates-rpms-with-files-entries-that-conflict-with-the-rpm-spec-how-to

OR

Lensfun had a similar issue recently:

The problem can be avoided by passing an extra parameter to cmake, together with a list of directories that should be excluded from the file list of the RPM.
What I did was:
$ cmake -DCPACK_BINARY_RPM:BOOL=ON -DCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION="/usr/local;/usr/local/bin;/usr/local/include;/usr/local/lib;/usr/local/lib64;/usr/local/share" ../

Found those when I was trying to track down what caused this issue with the rpm.

pnahratow probably already knows how to fix since he already has before.

[kduske]

@pnahtarow Look at the merge commit: https://github.com/kduske/TrenchBroom/pull/1297

I bungled that one up.

[pnahratow]

I'm not sure I understand. All I see is that the featurebranch never really went into develop. As far as I remember the whole thing also depended on the switch to using wxStandardPaths instead of the old way.

Well you just decide how to to proceed from here and I'll be happy to assist.

[kduske]

I don't understand it myself, it looks like I merged it into the wrong branch or something. I have just updated my own feature/1163 branch with all changes on develop that have happened since then. Now I'm waiting for the builds to finish.

[kduske]

Ok, I merged that branch finally. Thanks!

[ericwa]

Do we want it on the release/v2.0.0 branch as well? Currently only in develop

[kduske]

Yeah, good point.

[kduske]

Ok, it's on release/v2.0.0 now, too.

[ericwa]

Fixed by a56e99231d2fc75aa687382d388c4d7ca2a88e89 912314d34cf20be4d0468845787c3cf2de1fdf27 85c3c67e0330ef2f3f0821aeeebaf221cd81418d

[etc0de]

Thanks for looking into this so quickly!

I don't understand the order of anything listed on http://kristianduske.com/trenchbroom/downloads.php?platform=linux_rpm but the one marked as "latest" in the green box still has this bug.

Do I simply need to wait until the RPM packages are updated?

[kduske]

They are listed by release date, descending, so latest is first. You will have to wait for new builds, which will happen soon.