Best way to overlay a filesystem for a Wine app?

Scott Ritchie scott at open-vote.org
Sun Jan 29 17:58:32 CST 2012


On 01/29/2012 02:38 PM, Dan Kegel wrote:
> Hi Scott,
> I agree with what Vrit said.
> 
> Here's what I recall learning from helping package Picasa:
> - don't package the installer

Right, run the installer and use the contents of the result as the
packaged files.

> - rely on the system's update manager to pull updated versions of the
> package from the repository

This may not be a fast-enough option for some apps, such as online games
that need to keep everyone in version sync.  Even in an ideal case where
the company was 100% behind the Ubuntu package and kept it in sync with
their release process, there is still no current way for the Windows app
to tell Apt to update its package.

> - install everything read-only into /opt/companyname/appname
> - start the app using a shell script that creates a wineprefix on 1st run
> - The wineprefix should have real directories (so the app can create
> files in Program Files, ugh), should symlink to all the readonly files
> in /opt, and have real copies of any files that can't be read-only
> As Vrit said, the script that creates the wineprefix is very
> app-specific, but once you write one, it's probably easy to write the
> next one.

Perhaps I'm speaking from inexperience with either, but wouldn't a
unionfs-fuse overlay be simpler and cleaner than this since you wouldn't
have to worry about the app-specific stuff at all?

> - If you are running your own repo, you should put exactly one app per
> repo.  Otherwise you run into trouble because Canonical would want to
> review all the apps in the repo every time you update any one of them.
> 

This is already how apps work in the App Store - commercial apps get
their own repos, if they require payment then it's a private launchpad
PPA, and the user gets a unique access key when they buy it.

> So no overlay filesystem needed, symlinks should usually suffice.
> 
> (Picasa also went further and bundled a snapshot of wine, too, and
> modified the app slightly to display unix paths, which required adding
> one little extension to wine.  I'm sure the wine patch is around if
> someone wants it.  And since it was in a non-ubuntu repo, it had to do
> a strange song and dance to avoid autoupdates being disabled when the
> user upgraded to a new version of ubuntu.  This was considered safe
> because picasa was fairly well self-contained and maintained, and was
> unlikely to break on system updates.)

This patch would be interesting if you could dig it up.  I don't know if
Alexandre would accept it, but ideally it would be part of Wine and
turned on via an environment variable or command line switch.

> 
> In case you want to look at picasa's scripts, the download page seems
> to be gone, but the repo seems to still be there:
> 
> http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i386.deb
> http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd64.deb
> 4ecf30186ce76430a7791cee2608f47e07b015e6  picasa_3.0-current_amd64.deb
> fe8e83b29a10b5d663e87861d85512faea036c06  picasa_3.0-current_i386.deb
> 
> Still installs and runs ok on 11.10.

Thanks!

Thanks,
Scott Ritchie



More information about the wine-devel mailing list