On 01/30/2012 01:58 AM, Francois Gouget wrote:
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.
Well, provided the app doesn't change it's registry entries, it should be ok then. But couldn't we extend Wine a bit in the other case?
For instance, maybe app's changes could be merged in via Wine's normal method of updating the registry on (Wine) upgrade (/usr/share/wine.inf)? It would require giving Wine some sort of switch to point to a supplemental file.
- 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).
If the user never customizes the app-specific prefix with winecfg or similar, then copying the new registry should work yes?
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.
Do you mean upgrading while the filesystem is mounted? Or just any change at all?
- 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!).
Yeah the idea is to do this moving forward rather than create a universal linux package.
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.
Agreed, keys will be a problem.
Thanks, Scott Ritchie