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
