Best way to overlay a filesystem for a Wine app?

[Scott Ritchie]

Suppose someone wants to distribute a Windows application as a
traditional package, such as via the Ubuntu Software Center App Store.

Ubuntu requires these commercial packages:

1) Install into a unique namespace in /opt  (icons/.desktop excepted)
2) Store their user configuration in ~/.packagename or ~/.config/packagename

I have already packaged a super-simple Wine application this way.  This
was a single binary file that could be run from anywhere - all I had to
do was copy it into its own /opt folder and make a .desktop file that
declared a unique WINEPREFIX for it.

More complicated Windows applications, however, won't be doable with
this basic approach.  Specifically, Windows applications might:

1) Be distributed as installer files
2) Have self-updating mechanisms
3) Expect their own folder to be user-writable

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).

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.


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.

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.

Or have I missed something?

Thanks,
Scott Ritchie