Bug 371195 – app-arch/innounp - Inno Setup installer package extractor (Windows executable)

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Jared B. 2011-06-12 03:10:33 UTC]

This ebuild installs innounp, a CLI utility to extract files from Inno Setup packages commonly used as installers for Windows applications.  innounp is only available as a Windows binary, so this package installs the Windows binary and a wrapper script to execute it through wine.

Now I know a lot of people are going to read that and immediately think, "WTF?"  I know, the thought of native Windows utilities in portage is odd.  This is mostly an experiment to generate discussion about the topic, as well as a proof-of-concept to show how it could be done.

My rationale here is that there are many useful, open source programs only available for Windows.  innounp is one such utility.  I've been on a retro-gaming kick lately and bought several games from Good Old Games, which bundles its games in Inno Setup installers.  As far as I'm aware there's no native Linux utility to unpack Inno Setup installers, so much choices are limited to:

a) installing under Windows and copying the files (inefficient and requires Windows),
b) extracting files with innounp under Windows (still requires Windows)
c) installing under Wine and copying the files (inefficient and ugly), or
d) extracting files with innounp under Linux using wine (perfect!)

Obviously the last choice is the fastest and easiest option, assuming the requisite utility behaves properly under wine.  It's saved me a ton of time, and if something like this were to ever make it into portage the various game ebuilds could be updated to use it as well, completely eliminating the need for manual extraction or installs.

I'm not advocating allowing any and all Windows programs to be added portage.  In fact, I'd say the vast majority would be inappropriate.  However, in cases where:

1. there is no (acceptable) Linux-native solution,
2. an open and/or freely-redistributable Windows solution exists, and
3. the Windows solution works perfectly under wine,

then I think it should be considered for inclusion.  We already have a great wine package in portage; let's further leverage that work.

Thoughts?  I tried searching for other discussions about this topic in bugzilla and the forum, but wasn't able to find anything.  If this topic has already been hashed out, could you please point me to the previous discussion?

[Comment 1 Jared B. 2011-06-12 03:11:00 UTC]

As for this particular 'proof-of-concept' ebuild, the only think I'm not happy about is where the .exe is installed.  I copied it to /usr/lib/wine/fakedlls, as that seemed like the best place where it would fit in (and it should always exist as wine is an RDEPEND), but it still doesn't seem quite appropriate.  Any suggestions on how this should be handled would be appreciated.  I think something like '/usr/share/wine/bin' would be appropriate, but nothing like that exists righ now.

[Comment 2 Jared B. 2011-06-12 03:12:29 UTC]

Created attachment 276727 [details]
app-arch/innounp-0.36.ebuild

[Comment 3 James Le Cuirot 2011-06-12 09:18:10 UTC]

I've only just been pointed to this bug but I have previously used innounp in an actual ebuild for bug #363719. Running Wine within an ebuild is probably even more controversial than packaging innounp but I gave a solid set of reasons to justify it in that bug report.

As to whether innounp should be packaged separately or just bundled together with the ebuilds that use it, the former wouldn't be a bad idea. I have already used it for Settlers 2, we're currently looking at Rise of the Triad and I plan to use it for FreeSpace 2. I think there are plenty more games on GOG that have Linux ports of some kind.

[Comment 4 James Le Cuirot 2011-06-12 10:26:36 UTC]

Created attachment 276801 [details]
app-arch/innounp-0.36.ebuild

Here's some improvements, primarily moving the unrar stuff to DEPEND (not RDEPEND) and adding app-arch/unrar-gpl.

I've realised that having this as a separate package is beneficial because it means that the ebuilds that use it can have a proper SRC_URI and don't need to use EAPI 4. games.eclass doesn't officially support EAPI 4 yet.

[Comment 5 Jared B. 2011-06-12 20:08:02 UTC]

Thanks for the feedback, James.  Couple questions for you:

1. Since we're both working on related ebuilds (and thanks for mentioning freepsace 2 - I'll hold off on that :-) ), I think it'd be helpful to standardize somewhat on how we use innounp.  From your last comments in bug 363719 it looks like you favor the separate package approach, and I'm leaning toward this as well.  Shall we go with that?

2. If so, are there any other improvements to the innounp ebuild that would make it more suitable to use by other ebuilds?  I see you're using some sandbox features, which I haven't messed with before.  Should any of that be applied here as well?

Also have another question specifically about your usage of it in the settlers2-data ebuild, so I'll post in that bug report.

[Comment 6 Jared B. 2011-06-12 20:09:04 UTC]

Comment on attachment 276727 [details]
app-arch/innounp-0.36.ebuild

obsoleting in favor of James' revision

[Comment 7 James Le Cuirot 2011-06-12 20:26:55 UTC]

> 1. From your last comments in bug
> 363719 it looks like you favor the separate package approach, and I'm leaning
> toward this as well.  Shall we go with that?

Yes please. :)

> 2. If so, are there any other improvements to the innounp ebuild that would
> make it more suitable to use by other ebuilds?  I see you're using some sandbox
> features, which I haven't messed with before.  Should any of that be applied
> here as well?

I gave this some thought myself. The sandbox variable only applies to Portage. It prevents Wine from writing outside the build environment. It wouldn't make sense to set it in the wrapper. I also add "2> /dev/null" because under Portage, Wine makes a lot of noise about the display and soundcard being unavailable. You won't see this noise outside of Portage unless something is wrong so I don't always want to hide that output.

A small eclass would actually be ideal here. I have doubts about whether the existing developers would want to take responsibility for something this unusual but I have long considered becoming a developer myself. I asked the Java team about it recently but they're a little busy with GSoC right now. I've since decided to learn to drive first before my wife beats me up. ;)

[Comment 8 Jared B. 2011-07-03 02:51:51 UTC]

FYI, I just added my first package using innounp to bug 181539.  James, I had a slightly different experience than you when calling innounp, so I made two changes to what you had done in your settlers2-data ebuild:

1. I still can't replicate the noexec problem you mentioned, so I skipped copying the file to workdir to save time during the unpack process (which, for the kingpin ebuild I was working on, is already way long).

2. The WINEARCH thing didn't work for me.  I can't remember the error message now, but wine would barf if I tried to set it to win32.  I removed that option and it worked just fine, so I left it out.  I'm on an amd64 system, so it should work for other amd64 users, and I'd also expect it to work for x86 users as well.

Just wanted to give you a heads up.

[Comment 9 Jared B. 2012-09-22 09:31:01 UTC]

FYI, a native Linux extractor for Inno Setup installers now exists, and is already in portage:  app-arch/innoextract.  I'm moving all of my ebuilds that were previously using innounp over to innoextract, so this innounp ebuild really isn't needed anymore.  It can be left here for reference if anyone wants to play around with it, but I don't think it has much use at this point.

[Comment 10 Julian Ospald 2012-09-22 09:55:46 UTC]

(In reply to comment #0)
> Thoughts?

definitely no.

Wine is highly experimental even though you might be able to play skyrim via this. Maintaining a package that might break with _every_ version bump of wine is simply impossible. (otherwise you might have to introduce slotting of wine, but even that does not solve all issues)

Most bugs related to that package will probably be RESOLVED CANTFIX or RESOLVED UPSTREAM, cause they are simply wine-related instability problems.

There is no real support from wine regarding any application that we might add. Neither will the developers of that application give meaningful support, cause we don't run it as it was supposed to.
Wine is not like a library that carefully extends it's API knowing that applications rely on it. It's just some random trial and error where you might be lucky enough to hit a nice spot. That might be sufficient for many users (including me in some cases), but it should never be considered for the tree.

[Comment 11 Sergey Popov (RETIRED) 2012-09-23 07:45:57 UTC]

I agree with Julian - wine-related stuff should be installed through wine itself(by hands or using winetricks). Perhaps you should offer innoupnp installer to be added into winetricks(if it has not already done yet).

Closing as WONTFIX