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
