Best way to overlay a filesystem for a Wine app?

[Scott Ritchie]

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