Hi Scott, I agree with what Vrit said.
Here's what I recall learning from helping package Picasa: - don't package the installer - rely on the system's update manager to pull updated versions of the package from the repository - 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. - 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.
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.)
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_i38... http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd... 4ecf30186ce76430a7791cee2608f47e07b015e6 picasa_3.0-current_amd64.deb fe8e83b29a10b5d663e87861d85512faea036c06 picasa_3.0-current_i386.deb
Still installs and runs ok on 11.10.
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_i38... http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd... 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
On Sun, Jan 29, 2012 at 3:58 PM, Scott Ritchie scott@open-vote.org wrote:
- 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.
In those cases, you would make the files updated by the game's launcher be read/write instead of read only symlinks.
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?
Yes. My experiences were in the context of making a single portable (in the old sense of the word) binary to run on all sorts of distros, even old ones with no union filesystem support at all, so we had to use symlinks. And my impression is that filesystem unions aren't quite ready for prime time. LWN has had a lot of articles about that (most recently last June? http://lwn.net/Articles/447650/ ) But perhaps you are only targeting the most recent Ubuntu, and have found that it includes a usable union mount of some sort.
When I try to script things that use fuse filesystems, I seem to need to add mystery "sleep 1" statements after issuing mount commands, which isn't exactly trust-inspiring. But maybe some other part of the system I was using was causing the delay.
(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.
This patch would be interesting if you could dig it up.
I don't see it standalone anywhere, but the source tarball used is linked to from http://code.google.com/opensource/wine.html, and the extension was probably kernel32.wine_get_unix_real_name().
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.
I doubt he would accept it. (Heck, he probably wrote it.) - Dan
-
Dan Kegel -
Scott Ritchie