Created attachment 442698 [details] games-roguelike/rimworld-0.0.14.1249e.ebuild Greetings, Rimworld [1] is a pretty popular, and very fun, indie game by Ludeon Studios [2], in the vein of Dwarf Fortress. It would be nice to have it in the tree, so I'm providing my ebuild to help out. Please let me know if there's any feedback on it. A couple of notes on the ebuild itself: 1. This is a commercial game, so this is a fetch-restricted binary ebuild. 2. The version numbering I've chosen is the best way I could find to track upstream versions within the constraints of Gentoo's versioning, while providing for bumps needing a rename only. This initial version, "0.0.14.1249e" translates as upstream's Alpha14e (which is build 1249). 0.0 -> alpha, 14 -> 14, 1249 -> build-number (the ebuild needs to know this because it's part of the directory structure 0 I think this is a Unity engine thing), e -> suffix after upstream's numeric version. 3. I tried for multilib support (because the game supports both 32-bit and 64-bit). I was kinda groping in the dark, so please let me know if I didn't do it right. 4. There are some unzip warnings about some "local" Russian filenames not matching "central". This seems like a bug with Unity's packaging, but should be harmless because it chooses the central versions, which look like the correct unicode ones to me. BTW, these warning were fatal unless I inherited unpacker.eclass, so that's why that's there. [1] http://rimworldgame.com/ [2] https://ludeon.com/
CC games team to see if they are interested.
Note: The attached ebuild still works for the current version of Rimworld, Alpha 15c. Just needs rename to rimworld-0.0.15.1284c.ebuild.
Mike, given that Rimworld is a commercial game and as such only people owning it would be able to fully test the ebuilds, would you perhaps be willing to become the proxied maintainer of this package? You would then be the person working on the ebuilds and someone from the dedicated Gentoo team [1] would push your changes to Portage. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers
(In reply to Marek Szuba from comment #3) Sure, I can do that. I *would* like for someone to take a look at the ebuild and at make sure it looks right (particularly my guess at multilib treatment). If someone can step up who can test the 32-bit build, that would be great, too. I have no way to actually test that.
Great! We will of course have a look at your ebuilds, that's what the Proxy Maintainers project is for. It would be good if you could come to IRC at some point to discuss the matter, it is faster that way... Meanwhile, have a look at the links in the Resources section of the page I have linked, they will help you validate your ebuilds and give you some hints on the best way of submitting your ebuilds. Overall the ebuild as it is looks quite okay but there are a few things which should still be improved: * the games eclass is deprecated, just conduct the necessary operations by hand; * every file-system operation should be followed by an "or die in case of an error" clause unless it really doesn't matter if the operation succeeds or not. Yes, even rm - in theory it *can* fail; * I think you should commit the Ludeon EULA to Portage and use that as LICENCE instead of using all-rights-reserved; * there is no need to inherit the unpacker eclass; * you've already got "RimWorld" assigned to ${HUMAN_PN} so just use that elsewhere in the ebuild instead of repeating the literal string; * come to think of it, you might consider generating ${HUMAN_PN} from ${PN} too; * there are a couple of places where variables are used unquoted. Regarding the testing on x86, the common way of doing that these days is to set up a chroot environment on an amd64 system. Until it has been tested though, just drop ~x86 from KEYWORDS. PS. I think we might have to revisit the subject of version numbers at some point.
Hi, any news on this? If not, we would like to close this bug as WONTFIX (for now anyway) following the usual 30 days of waiting.
