Best way to overlay a filesystem for a Wine app?

[Vit Hrachovy]

Hi Scott,
I've been addressing similar issues with my DosBoxed games project.

> More complicated Windows applications, however, won't be doable with
> this basic approach.  Specifically, Windows applications might:
>
> 1) Be distributed as installer files

Debian packaging rules state the program should be installed ready to 
use. Most installers can be scripted, though. You're probably aware of 
the problems rising from distributing installer only:
   * packaging mechanisms won't be leveraged
     * you'll have to write and maintain install/uninstall scripts
     * you'll have no way to detect and repair possible corrupted files
     * you'll delegate package security mechanisms someplace else
     * in case of multiuser system the program data would be duplicated 
across their homes

> 2) Have self-updating mechanisms

The approach that fits best with system packaging mechanisms would be to 
leave package updates on distro maintainers and disable autoupdating in 
the application.

> 3) Expect their own folder to be user-writable

I've solved that by app run script that creates app folder in user's 
home, symlinks all RO data from /opt and copy RW data to the folder. 
This approach is tightly app-specific. It addresses RO data sync problem 
during package update. However it requires taking care of syncing shared 
RW data from /opt to user home in the app run script.


> One ugly not-quite-solution would be to just have the package put the
> installer in opt, provide a link to it, and expect the user to install
> like he would a downloaded application (and then use a different
> .desktop file to actually run the program).

See comment to #1. This might work for single user machine, but not for 
multiuser server. Also it makes most security features of packaging 
system unusable for these apps.

> Slightly better is to just copy an entire /opt prefix template into user
> space on first run, and then let it go on its own way after that.  An
> app which didn't self-update, however, would then be unable to benefit
> from an updated version of the system package.

Same like before - security problems + disk space requirements rise  per 
user base. Consider multiuser system with user quotas on /home. It may 
seem an overkill until you realize that for example modern game installs 
consists of 4-8GB of static data. In case of system with 4-5 users who 
want to play the game, this multiplies the storage space requirements as 
well as prolongs the first run startup time.

> A more complete solution would have a prefix in the user space, but
> files inside it would actually be those residing in /opt.  A system of
> symlinks might work, but if a package update introduced new files those
> would not be available without complicated scripting to add the links.

That was my solution for apps that need RW access to their dir or need 
RW access to their binaries. App run script ensures symlink health at 
each start (solves package update problem). However, each app has to 
have its own crafted and maintained app run script.

> To me, this sounds an awful lot like an overlay file system.  Would
> unionfs-fuse be the correct solution here?  The .desktop file that sets
> the Wine prefix and also launches the app could mount the FUSE
> filesystem, and the user-space Wine prefix's files could take priority
> over those in /opt.  Stuff like user-modding and update/repair systems
> could work properly in that context as well.

This seems elegant and easy solution to me. It may address most of the 
problems, except the one when app needs to open its own data/libraries 
in RW mode and writes to them. In that case those data/libraries won't 
benefit from package system update features and their syncing would need 
to be handled somewhere in crafted app-specific script.

Regards
Hark