https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639 Bug ID: 4639 Summary: dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it Product: Package Reviews Version: Current Hardware: x86_64 OS: GNU/Linux Status: NEW Severity: enhancement Priority: P1 Component: Review Request Assignee: rpmfusion-package-review(a)rpmfusion.org Reporter: rosser.bjr(a)gmail.com CC: rpmfusion-package-review(a)rpmfusion.org namespace: nonfree Now that Dwarf Fortress is in the distribution, I guess I should submit this review request too. Spec URL: https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/rpmfusion/dfhack.spec SRPM URL: https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/rpmfusion/dfhack-0.43.0... Description: DFHack is a Dwarf Fortress memory access library, distributed with a wide variety of useful scripts and plugins. For users, it provides a significant suite of bugfixes and interface enhancements by default, and more can be enabled. There are also many tools (such as workflow or autodump) which can make life easier. You can even add third-party scripts and plugins to do almost anything! For modders, DFHack makes many things possible. Custom reactions, new interactions, magic creature abilities, and more can be set through Scripts for Modders and custom raws. Non-standard DFHack scripts and inits can be stored in the raw directory, making raws or saves fully self-contained for distribution - or for coexistence in a single DF install, even with incompatible components. For developers, DFHack unites the various ways tools access DF memory and allows easier development of new tools. As an open-source project under various copyleft licences, contributions are welcome. FAS Username: tc01 Namespace: nonfree Why not in Fedora: dfhack is fully open source. However it depends directly on Dwarf Fortress, a nonfree game (nonfree/dwarffortress); dfhack communicates directly with the running dwarffortess process. Thus it must be in nonfree. Notes: This package is a bit messy, which is one reason I've been hesitant to open a review request for it. There are a number of points to note, most of which are documented in the spec itself as well (it is quite well commented). 1. Upstream uses a lot of git submodules, but also the build fails if .git metadata isn't present. However, when I inquired upstream, they were not interested in releasing a "source tarball" from which DH could be built without doing additional git checkouts. Therefore I wrote a script (see link below) to *actually* generate the dfhack tarball for which I've been managing releases. That is why there is no source url. https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/rpmfusion/build-dfhack-... 2. There are a number of bundled bits with no support for unbundling. Worse, many of the bundled bits have been forked by dfhack, meaning that it's basically never going to be possible to unbundle (the most egregious example is likely a dfhack fork of protobuf). 3. dfhack has a plugin (and script) architecture. Most plugins are included in dfhack itself, but some are distributed and maintained separately, somewhat like the Linux kernel. (Note that one of the in-tree plugins, stonesense, is distributed here as a subpackage, since it contains a fair amount of data specific to itself). I have been meaning to figure out a better way to do out-of-tree dfhack plugin builds, but for now I just have this package fill in and install a pkgconfig file. 4. ...unfortunately, dfhack plugins need to link statically against a helper library, "dfhack-version.a", and so a static devel package is needed too. 5. One of dfhack's plugins is an interpreter for ruby scripts, which works by directly trying to dlopen "libruby.so" (the intention was to ship a bundled libruby that would be downloaded during the build, but I upstreamed a patch to disable the download). Currently, therefore, I've made dfhack Require libruby-devel as a runtime dependency. While I guess I could patch this out, it would then mean that dfhack needs to be rebuilt whenever there's a ruby soname bump. I think those are the major pain points with the current state of the package. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.