Created attachment 270079 [details] return-to-the-roots-0.7.2.ebuild Return to the Roots is an open source rewrite of The Settlers 2 that uses the commercial data. The game is still available to purchase from gog.com but unfortunately they use a very unfriendly packaging format called Inno Setup. The only way to extract this is to run the interactive Windows executable or to use innounp, a command-line open source extractor that uses the original Inno Setup code but still requires Windows. The code is very Windows-specific Delphi and a nightmare to understand so there's not much chance of it ever getting ported. Nevertheless, I was determined to support this in the ebuild even if it meant running Wine during the process. I totally understand that this is highly controversial and has probably never been done before but I have a lot of experience in writing ebuilds and I am confident that the end result is sufficiently safe and reliable to go into the tree. - The program is not interactive. - It is command-line based and does not require X to be started, as it still works with DISPLAY unset. - It plays nicely with the sandbox. Wine will try to write to some places in /dev while configuring sound but the sandbox silently blocks these without issue. - Even if the sandbox is disabled, these writes are harmless. - EAPI4 enables us to only support this on amd64 and x86 while still allowing other architectures to install from the CD without any ugly die hacks. - If we don't allow this then users will have no choice but to go out of their way to extract the files with Wine (or Windows) themselves. EAPI4 isn't officially supported by games.eclass yet but I tried it locally and it does at least work for everything that this ebuild needs. I don't have the original CD but I'm fairly sure that it has the same layout as the gog.com download. If anyone can confirm that it works with the CD, I'd be very grateful.
Created attachment 270081 [details, diff] paths.patch A small patch to adjust the paths for Gentoo.
Created attachment 270083 [details] settlers2-data-1.ebuild The data ebuild.
Created attachment 270085 [details] settlers2.png A nice icon I made. This goes with the data ebuild.
Created attachment 270103 [details] settlers2-data-1.ebuild Just tried it on another machine and had to add /var/cache/fontconfig/ to the sandbox list. Hopefully no more are needed. Maybe I should just use /?
Created attachment 270111 [details] return-to-the-roots-0.7.2.ebuild I noticed some TEXTRELs when building on x86. This fixes those. I'll report this upstream if it hasn't been fixed already. I'll also request source tarballs.
Created attachment 270141 [details, diff] fpic.patch Turns out that wasn't the only problem. The rest of the code was being built with -fPIC under amd64 despite the fact that it was static. I gather this incurs a performance penalty. Here is a patch to address all the -fPIC issues. This has now been submitted upstream.
Created attachment 270143 [details] return-to-the-roots-0.7.2.ebuild
Created attachment 270175 [details] return-to-the-roots-0.7.2.ebuild Source tarballs are now being provided. The -fPIC patch has also been accepted in a slightly modified form. :)
Created attachment 270177 [details] File-listing for Die Siedler 2 Gold
Created attachment 270183 [details] settlers2-data-1.ebuild Thanks for that, Wilke. Your CD has the files in an S2 subdirectory so I've made the ebuild check for that. Please give it a try.
I tried, but unsurprisingly it failed with "no support for EAPI=4 yet". How do I circumvent that?
As I just mentioned at http://forums.gentoo.org/viewtopic-p-6654689.html#6654689, you can either modify games.eclass to add EAPI4 or modify the ebuild to use EAPI3. See the link for more info.
Created attachment 276803 [details] settlers2-data-1.ebuild Here's a new data ebuild that gets innounp from a separate package. Another user pointed me to bug #371195 and after thinking about it, I realised that there were some benefits to this approach. A proper SRC_URI can now be given and it is no longer necessary to use EAPI 4.
Hey, James. As mentioned in bug 371195, I'd like to stay somewhat consistent in how we use innounp in the game-related ebuilds. So, I'm looking at this example as a model for how to write my own, but I don't quite get the reasoning for some of it. Specifically: 1. the setup exe shouldn't need to be copied first. You can use -d to specify the output. Eg, something like: innounp -x -d${WORKDIR} ${EXE} 2. I don't understand the $HOME/wine stuff at all. What's the purpose? Ditto, to a lesser extent, for setting DISPLAY. I'm guessing it has something to do with sandboxing, but I don't know why we'd need to create and use a special directory for this. 3. Is WINEARCH necessary, or are you just being explicit? I can call innounp manually without specifying that and wine is able to figure out how to run it. Just want to make sure I'm not missing something. Lastly, a more general (and long-winded) question: I've seen other game ebuilds (like rott, for example) that use the cdinstall flag differently than here, where it's generally set in the game binary/engine build rather than the data build. If set, it pulls the game data in from a CD or installed location, or pulls in a game-data ebuild to do the job. If not set it simply informs the user to manually copy files to the appropriate location. In this case it looks like it's being used to distinguish between using the CD or extracting the GOG package. For the sake of consistency, with those other ebuilds, what would you think about using cdrom_get_cds and ${CDROM_SET} to check for either the original CD or the GOG package (or, possibly, the extracted files) and then just doing the right thing regardless? It'd take some more work in the ebuilds to handle all of the variables, but the end result would be that the user just needs to point CD_ROOT to a directory containing the source data, and pretty much any format, and be done with it. cdinstall could then be used to distinguish between automated or manual data installs. It's a thought, and probably more of a long term change, but wanted to bring it up for discussion.
(In reply to comment #14) > 1. the setup exe shouldn't need to be copied first. You can use -d to specify > the output. Eg, something like: innounp -x -d${WORKDIR} ${EXE} The output directory isn't the problem. The problem is that /usr/portage (or /usr/portage/distfiles) may well be mounted with noexec because nothing is ever usually executed there. Even though we're not really executing the file, for some reason (maybe a bug), innounp will not read the file unless the filesystem allows it to be executed. Try it if you can. > 2. I don't understand the $HOME/wine stuff at all. What's the purpose? Ditto, > to a lesser extent, for setting DISPLAY. I'm guessing it has something to do > with sandboxing, but I don't know why we'd need to create and use a special > directory for this. It is entirely possible that you may be performing this emerge without X running. Even if it is running, we obviously don't want anything graphical appearing so DISPLAY= prevents that entirely. innounp itself isn't graphical but Wine does sometimes display message dialogues for various reasons. Wine is extremely picky about the HOME and WINEPREFIX directories. In particular, it won't run if HOME belongs to another user. Under Portage, HOME is actually ~portage/games-strategy/settlers2-data-1/homedir and this is owned by portage:portage. If you are running without FEATURES=userpriv then Wine gets executed as root, who is not the owner of HOME. Hence we need to reset HOME to a directory that root does own like the ${HOME}/wine directory that was just created. > 3. Is WINEARCH necessary, or are you just being explicit? I can call innounp > manually without specifying that and wine is able to figure out how to run it. Just want to make sure I'm not missing something. Are you on a 64-bit machine and have you built Wine with 64-bit support? I really don't know why but unless I give WINEARCH=win32, the process dies horribly. Something to do with the sandbox if I remember correctly as it works fine outside of Portage. innounp is a 32-bit application so it does make some sense. I'll answer the rest tomorrow.
> Wine is extremely picky about the HOME and WINEPREFIX directories. In > particular, it won't run if HOME belongs to another user. Under Portage, HOME > is actually ~portage/games-strategy/settlers2-data-1/homedir and this is owned > by portage:portage. If you are running without FEATURES=userpriv then Wine gets > executed as root, who is not the owner of HOME. Hence we need to reset HOME to > a directory that root does own like the ${HOME}/wine directory that was just > created. Actually I now remember that it's a little more complicated than this. It also cares about the owner of WINEPREFIX. However, if you try to create an empty WINEPREFIX and then set WINEARCH then Wine gets confused and bails out, complaining that the given WINEARCH doesn't match the architecture for that directory even though that directory is empty. We therefore have to let it create WINEPREFIX by itself but it won't do that if you're not the owner of HOME. :)
(In reply to comment #14) > In this case it looks like it's being used to distinguish between using the CD > or extracting the GOG package. For the sake of consistency, with those other > ebuilds, what would you think about using cdrom_get_cds and ${CDROM_SET} to > check for either the original CD or the GOG package (or, possibly, the > extracted files) and then just doing the right thing regardless? It'd take > some more work in the ebuilds to handle all of the variables, but the end > result would be that the user just needs to point CD_ROOT to a directory > containing the source data, and pretty much any format, and be done with it. > cdinstall could then be used to distinguish between automated or manual data > installs. I've never really seen the point of manual data installs. There's a good chance that the user will copy the files with the wrong permissions. They'll probably also copy a lot of files that aren't actually required. It may also be necessary to make adjustments to the files or set the filenames to have a specific case. A good example of these points is Unreal Tournament, although that doesn't have a separate data ebuild. All that aside, there's a good reason for my approach in the case of GOG games. Obviously Portage cannot download the game from GOG automatically but it can still check for the presence of the download automatically thanks to fetch restrictions. Notice the F and f here. [ebuild RF ] games-strategy/settlers2-data-1 USE="-cdinstall" 279,997 kB [1] [ebuild Rf ] games-strategy/settlers2-data-1 USE="-cdinstall" 0 kB [1] The first is what we see when the download is not present. The second is what we see when it is. If this package is being emerged as part of a list then Portage will use this property to prevent a missing download from causing emerge to bail out early. If I remember correctly, it leaves that package till as late as possible. For all this to work, SRC_URI cannot be empty. This also allows the checksum of the download to be checked in the usual way. So why can't we do this without cdinstall? Well, it's true that we only need some arbitrary USE flag to filter the entry in SRC_URI, it doesn't have to be cdinstall but to me, this is what cdinstall means. With a downloaded game, you're not installing from a CD! :) I wouldn't want to introduce another flag, I think that would be even more confusing.
There are actually some counterexamples. While it's true that many games use cdinstall in this way, some don't such as Quake 3. This has a straight dependency on quake3-data. Another approach is used by Duke Nukem 3D. This doesn't depend on duke3d-data at all. It only suggests you emerge it in pkg_postinst.
Sorry for the late reply - forgot to CC myself on this bug. :-) So to hit some of your points, in order: 1. on the noexec thing... that's just weird. I can't seem to replicate it on my system, though. I keep all my game files on my NAS and access them through NFS. I just tried remounting that export with noexec and innounp still worked fine for me. Don't understand why it'd behave differently for us. If there's a chance it could fail for other users and this would always fix it, though, then adding the extra copy step would probably make sense. My main concern is that some of the GOG packages can be quite large (such as Freespace 2, which is 1.5 GB), so that's a lot of data to be unnecessarily copying around. Edit: Maybe it's another odd behavior difference between running as a user and running under portage, like the next two items? 2. OK, so DISPLAY= is a better safe than sorry thing. No arguments there. The HOME thing I still find odd, but it looks like you've done far more testing here (I haven't yet actually tried running this from an ebuild), so I'll defer to your judgment. 3. I do run amd64 w/ USE=win64 enabled, but I guess your later post about this explains why that works for me manually but it fails during an emerge. Again, better safe than sorry. 4. I'll need to think about your cdinstall response some more. I'm not sure I agree with your points, but I need to give it some more thought. Thanks for the thoughtful reply. Will post back again once I've had some time to digest.
*** Bug 411247 has been marked as a duplicate of this bug. ***
this is also available in sunrise and "hasufell" overlay (except the data-ebuild)
(In reply to comment #21) > this is also available in sunrise and "hasufell" overlay (except the > data-ebuild) That's a little misleading, your ebuild is quite different to mine.
correct games-strategy/s25rttr is in sunrise and hasufell overlay Feel free to contribute to the sunrise overlay which is a user-overlay. http://www.gentoo.org/proj/en/sunrise/
+ 12 Nov 2012; Julian Ospald <hasufell@gentoo.org> +s25rttr-0.8.ebuild, + +files/s25rttr-0.8-cmake.patch, +files/s25rttr-0.8-soundconverter.patch, + +metadata.xml: + initial import wrt #363719
