On Fri, 27 Jan 2012, Scott Ritchie wrote: [...]
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.
The main issue with copy-on-write overlay filesystems is that they cannot deal with registry files for two reasons: * First, once a file has been written to and thus copied to the user's wineprefix, it will never be updated when you upgrade the application's package. This means after an upgrade the user's system.reg and user.reg files (the latter containing the dll overrides) will be unchanged which may cause the application to be broken. * The second issue is that the registry really contains both application data and user data. The former should be upgraded while the latter should be preserved. So neither a copying the new registry files nor preserving the old registry files policies are appropriate (and these policies are the only two available to overlay filesystems).
Besides that there are other issues, most of which Dan already mentioned: * As far as I know most overlay filesystems don't deal well with changes in the underlying filesystem. This pretty much breaks the upgrade scenario. * They are not available on all Linux distributions (not to talk about Mac OS X or FreeBSD). But I guess this is fine for a latest-Ubuntu-only approach (like for menus and the trash!).
Another issue is applications that require a license key to be entered during installation. This causes trouble for both the overlay and symlink approaches since both have the packager install the application and then ship the installed image... along with its single license key. So for these applications a way to enter the license key on first run has to be found.