Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: RPM .spec file for packaging Dwarf Fortress on Linux  (Read 1600 times)

waveclaw

  • Bay Watcher
    • View Profile
RPM .spec file for packaging Dwarf Fortress on Linux
« on: August 25, 2014, 09:00:53 pm »

I have always appreciated the Linux builds, even if not the vast tracks of time sucked into another sock-wielding adventure or fractal-layout fortress. As I depended quite a bit on the community resources I am giving back this little bit.

I have written an RPM specfile to build an RPM for install DwarfFortress as a normal native Linux application (while patching the .png support for the .bmp bug.)

This is just straight, vanilla DF installed as a native application.

The Linux port uses some very old libgraphics and the game just assumes it will run out of the local directory.  The package goes through some effort to workaround these behaviors.

This so far is working great on openSuSE 13.1 x86_64.  Your mileage may vary.  No warranty if this catches you or your pet's hair on fire.

This is a relocatable package so can technically be installed anywhere once built.  But by default it installs to /usr for all users.

The rpm puts:
  • the libraries /usr/lib
  • an enlarged script to run the game in /usr/bin
  • content files (raws, graphics) in /usr/share
  • source code in /usr/src
All of these files end up in properly versioned DwarfFortress sub-directories.

When run, the script copies the data in /usr/share to
~/.local/share/DwarfFortress/VERSION
as needed.

There is an application desktop file that should the script from a menu option in the GNOME, LXDE or KDE desktop environments for your pleasure. (Getting your own dwarffortress.png is left as an exercise for the reader.)

To use this:
  • build a normal RPM build environment
  • download DF to your SOURCES directory
  • make the patch0 based on converting .png to .bmp in the text files
  • make the patch1 binary patch by converting mouse.png to mouse.bmp in df_linux/lib/DwarfFortress
  • create a tarball containing the Makefile, configure script and dwarffortress.in template in your SOURCES directory
  • run 'rpm -ba dwarffortress.spec' on that specfile

I provide the following code public domain, except where copyright is assigned to Bay12Games.

This is a template for a desktop file
https://gist.github.com/waveclaw/46db39363d1602b4f69b

This is the template of the /usr/bin/dwarffortess script for running out of the local user's home directory.
https://gist.github.com/waveclaw/0c315a5c4fd902bdd681

This is the Makefile for processing the two above.
https://gist.github.com/waveclaw/828abfca079e7da7a2cd

This is the rpm specfile itself.
https://gist.github.com/waveclaw/23af0925e855438ba4bf

I does require that the appropriate df_linux version be downloaded from Bay12Games.  Due to the copyright, I cannot provide built RPMs for DwarfFortress.  Only Bay12Games can do that.

Now, if the libgraphics issue, http://www.bay12games.com/dwarves/mantisbt/view.php?id=2688, were resolved then both the patches could go away. The patches are not fun to re-create for every version.  Particular the binary patch which uses xxd.

Suggestions are to switch to using launchers from the http://dwarffortresswiki.org/index.php/DF2014:Utilities page or perhaps even including some of the mod work from the giant git repository.

.deb packages for Debian based distributions like Ubuntu might be possible using alien or FPM, the 'friendly' package manager.
Logged

Artanis00

  • Bay Watcher
    • View Profile
Re: RPM .spec file for packaging Dwarf Fortress on Linux
« Reply #1 on: August 27, 2014, 04:30:19 pm »

I[t] does require that the appropriate df_linux version be downloaded from Bay12Games.  Due to the copyright, I cannot provide built RPMs for DwarfFortress.  Only Bay12Games can do that.

I'm confused by this. I admit I'm not familiar with the RPM spec or conventions, but Dwarf Fortress is can be redistributed, provided clear attribution of the source files and changes you made. Is there something on the RPM-side of this that restricts redistribution?

I've also seen .deb packages download binaries (usually flash and video drivers) that were non-free and couldn't be included in the official repositories. Perhaps something like that could be a solution?

Otherwise, this is really neat. I'm still trying to figure out the code (as I said, RPM, and package formats in general, are unfamiliar to me), but figuring out how to split apart the df folder must have taken a lot of work!
Logged
Git - fast, efficient, distributed version control system
Github - Free public repositories, issue tracking, wikis, downloads...

waveclaw

  • Bay Watcher
    • View Profile
Re: RPM .spec file for packaging Dwarf Fortress on Linux
« Reply #2 on: August 27, 2014, 11:48:21 pm »

The issue with redistribution is that this packaging format is mainly just to wrap vanilla Dwarf Fortress.  There is nothing original about it beyond the start script.  But without a clear actual license, DwarfFortress isn't licensed in a way that I could put this up on the http://openbuildservice.org/

rpmbuild is able to pull from the url on bay12games when you build the source and binary RPMs, so you can technically point the Source0 at that.  Flash and video driver redistribution are on very shaky legal ground when they don't come with a clear license or from the original company. 

(Urist McLawyer flees in terror:  "... Death, this does not bother me. Paperwork! Paperwork!  I must flee!"  Urist McLawyer doges.  Urist McLawyer has gone missing.  Urist McLawyer has been found dead in a murky pool of Red Tape.)

RPM specfiles are kind of like shell scripts where the emphasis is on using predefined macros (%patch, %setup, %files) and capturing all the meta-data about what is being packaged (version, license, name.)

The Debian package format has a lot more parts, many files and stricter syntax. It also requires some kind of actual license documentation, if I recall correctly.  But I think the license text can be bogus gibberish.

Figuring out how to split the df folder is pretty straightforward.  Toady has done a good job of organizing the current build for a project this size.  Without the need for the patches the only thing one needs to create a new RPM with this is just the Makefile, a launcher script and the specfile.  rpmbuild is able to pull sources straight off the web for you. 

All the Makefile does is bust the df_linux tarball out into parts and setup the script to handle copying the data.  It should be possible to rewrite the script to detect and offer the multiple versions if installed.  I have 0.40.06, .07, .08 and .09 installed.  Editing the script by hand can switch between each.

Really, with the work on some of the launchers like PyLNP the script could replace the launcher script I wrote.  There is a lot of work in PyLNP to handle all the non-vanilla things like patching in community mods or tile sets like Phoebus and even dealing with savefiles.

The source really should be in a sub-package, but sub-package making specfiles are more complicated than this.

If you are interested, the patching making process is:
  • Untar your df_linux
  • Copy that to df_linux.orig (cp -r to get everything)
  • Make the changes to df_linux/data/init/init.txt to replace .png with .bmp
  • Use diff to make the patch with diff -r df_linux.org df_linux > df_libgraphics.patch

The binary patch uses xxd.
  • Unpack the df_linux/lib/DwarfFortress binary from the tarball
  • Dump a text version of the original with xxd DwarfFortress > df.orig
  • Change mouse.png to mouse.bmp with sed -e 's/mouse.png/mouse.bmp/' < DwarfFortress > DwarfFortress.new
  • Dump a text version of the new executable with xxd DwarfFortress.new > df.new
  • Use diff to pull out the changes in the text file with diff df.orig df.new
  • Pick out the line with the mouse.bmp and put that into your xxd patch file

Removing the leading > character and throwing away the rest of the lines from the xxd patch.

Sadly, I've not been playing much since discovering on the forums that the value of room is far less when there are holes in the sides.  The difference with just -metal furniture- and engraved walls is a whole room quality level.

I had a nice little rotated multi-layer 3-D spiral fort based on a Julia fractal that worked really well for routing mine carts.  It is completely incompatible with using internal stairs to boost the value of even 2x2 or 2x3 rooms.  The layout cannot compete with the efficiency of the boring but very effective organics processing layout from the wiki.  Combined with a similar layout for ore and wood processing that organics processing layout can bridge the gap from small sub-20 forts up to 150 plus dwarfs..  Folding it into the Julia fractal doesn't work since the layout is sensitive to adjacency and the fractal forces work-spaces out to the edges.

On the plus side I got to blow through lots of graphing paper during boring meetings.  Pages of cryptic characters for chairs or tables and scribbled notes on trap mechanism counts lends a sort of nutjob air when someone is peering over your shoulder, too.
Logged