Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store.
Ubuntu requires these commercial packages:
1) Install into a unique namespace in /opt (icons/.desktop excepted) 2) Store their user configuration in ~/.packagename or ~/.config/packagename
I have already packaged a super-simple Wine application this way. This was a single binary file that could be run from anywhere - all I had to do was copy it into its own /opt folder and make a .desktop file that declared a unique WINEPREFIX for it.
More complicated Windows applications, however, won't be doable with this basic approach. Specifically, Windows applications might:
1) Be distributed as installer files 2) Have self-updating mechanisms 3) Expect their own folder to be user-writable
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).
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.
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.
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.
Or have I missed something?
Thanks, Scott Ritchie
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:
- 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
- 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.
- 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
Hi Scott,
Scott Ritchie wrote:
Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store.
You may want to look at the pptview package from Debian/Ubuntu. I don't know of any other Windows applications that are already packaged like this in the repositories. I do not think it would be bad to have more Windows applications available through a repository in such a way.
http://packages.ubuntu.com/lucid/pptview
Best regards, Julius
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.
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
On Mon, 30 Jan 2012, Scott Ritchie wrote: [...]
If the user never customizes the app-specific prefix with winecfg or similar, then copying the new registry should work yes?
Application configuration data (think Tools -> Options menu) is often stored in the registry...
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?
It's definitely an issue in the former case. I don't know but would not be surprised if it is also an issue in the latter.
-
Francois Gouget -
Julius Schwartzenberg -
Scott Ritchie -
Vit Hrachovy