migrating windows applications by packing wine+app in a deb?

liberavia · Post by **liberavia** » Fri Jun 04, 2010 6:32 pm

Hello,

I recently posted my experimental thoughts in the playonlinux forums, but I really want to open all possible channels to get feedback for the idea to deliver a complete (for the certain windows-app optimized) wine-structure, windows app and all nessassary wrapper scripts for processing the app in a deb.
This would mean that every single application(-group) brings its own fitting wine-version.

The advantages would be:
- Better migration of popular win apps through beeing integrated in the package-management-system.
- No version incompatibility problems (despite an app-update the windows-way)
- No installation barriers
- Possibility to exactly match certain wine configuration for the app its delivered with
- centralized updating, repositories -> software-center could be technical possible

Problems might be:
- Performance issues if more than one app+wine instance is running
- Security issues, but might be controllable via apparmor for example

Problems to deal with:
- How to build a standalone-wine instance which the wineprefix for the certain application can deal with
- Licensing questions at the install of an app has to be ported to preinst-scripts

Whats your opinion of packaging single applications?

It was the port of teamviewer for linux that inspirated me to think about this issue.

I unpacked the deb an had a look on the package-structure and scripts. Here is what I found out until now:
http://www.playonlinux.com/en/topic-353 ... iewer.html

Regards

André

oiaohm · Post by **oiaohm** » Fri Jun 04, 2010 11:45 pm

Fix the bug of bugs first. liberavia

"Wine does not support multi user install. of applications."

Basically fix is core issue of wine. Would allow global installs of applications into prefixs shared being users.

Problem is its not a simple bug to fix. It means implementing users in wine.

Native porting of applications is always better than even doing this. liberavia

Security issues are not addressable by apparmor or anything else for share multi user installs. Wine design has to be corrected so they can do their job. Basically secuirty takes us back to the bugs of bugs doing this.

Performance issues don't get better or worse dependent on the numbers of wine running most of the time Wine is heavier than native program doing the same job. Different versions add load. But wine does support multi versions of wine installed. Packager insist on installer wine is a format that only supports 1. Its not required.

There is no valid reason to put a copy of wine with every application. Ie make package dependent on the version of wine it requires and have that installed. Save disk space. Really a 3 package design would be wise.
1) Wine package ie containing wine it self.
2) Application and data package
3) Wine version selection package and reg's for the application and start menu entrys. This could also contain wine version particular tweaks for the application.

With dependencies 3 can trigger the install of the other 2. Also its possible to have this without 2 as well.

This way when application is found to be able to run with newer wine. Only the small joining package would have to be downloaded.

Licensing question is simple. Don't have the installer in the deb for unsupport instead have it ask for the disk/media just like quake2 and on of the quake games do for getting the game data from the demo. And have a way for end user to wrap binary in if they are legal owner for major deployments. No license troubles. Yes 3 package design does make doing this simpler.

Gert van den Berg · Post by **Gert van den Berg** » Sat Jun 05, 2010 3:51 am

AS far as I know, the Linux version of Picasa does something like
this? (Not sure how its packaged)

liberavia · Post by **liberavia** » Sat Jun 05, 2010 5:42 am

I got an answer

oiaohm wrote:Fix the bug of bugs first. liberavia

"Wine does not support multi user install. of applications."

Basically fix is core issue of wine. Would allow global installs of applications into prefixs shared being users.

Problem is its not a simple bug to fix. It means implementing users in wine.

And because its not simple fixing this, i think about creating workarrounds like teamviewer or picasa does. Have you looked the bash scripts of teamviewer for example? wine + app lies in opt. The menu entry which is created while the installation (postinst) of the package, calls a start script which creates (if not done yet) a structure of the app into the current home folder, including reg's and symlinks pointing to the wine install in opt which it is delivered with the package.

Couldn't that be a good way to deal with the core problem?

oiaohm wrote: Native porting of applications is always better than even doing this. liberavia

Full ack, but you know that this is a "chicken or the egg" dillema. And if a certain app runs fine with a certain wine-version, why not pack them together as a working unit.

oiaohm wrote: Security issues are not addressable by apparmor or anything else for share multi user installs. Wine design has to be corrected so they can do their job. Basically secuirty takes us back to the bugs of bugs doing this.

Currently I don't feel be able to solve the core problems, but i feel being inspirated to work them arround, and try to minimize them as good as I can.

oiaohm wrote: Performance issues don't get better or worse dependent on the numbers of wine running most of the time Wine is heavier than native program doing the same job. Different versions add load. But wine does support multi versions of wine installed. Packager insist on installer wine is a format that only supports 1. Its not required.

Its clear that it produces more load then it would run natively, especially if there would be multiple instances of wine. I hope I got your last sentence right, but if we look on the teamviewer package-dependencies, you won't find wine at all.

oiaohm wrote: There is no valid reason to put a copy of wine with every application. Ie make package dependent on the version of wine it requires and have that installed. Save disk space. Really a 3 package design would be wise.
1) Wine package ie containing wine it self.
2) Application and data package
3) Wine version selection package and reg's for the application and start menu entrys. This could also contain wine version particular tweaks for the application.
With dependencies 3 can trigger the install of the other 2. Also its possible to have this without 2 as well.
This way when application is found to be able to run with newer wine. Only the small joining package would have to be downloaded.
[/qoute]

I would say this would be an optimization issue. My example application wich i want to use for my experiments has 8 apps included, so it's clear that i would generate a package like apname-winelayer and a single package for each app which are depending on this layer.

oiaohm wrote: Licensing question is simple. Don't have the installer in the deb for unsupport instead have it ask for the disk/media just like quake2 and on of the quake games do for getting the game data from the demo. And have a way for end user to wrap binary in if they are legal owner for major deployments. No license troubles. Yes 3 package design does make doing this simpler.

Games are a special issue and currently not in my mind. If a game should be ported this way you would also put the library, graphics, sound etc in a single package. Currently I'm more focused on apps that are used in my company and prevents me from switching to linux-desktops.

Gert van den Berg wrote: AS far as I know, the Linux version of Picasa does something like
this? (Not sure how its packaged)

Great I will have a look on my hopefully second example

.

Regards

Gert van den Berg · Post by **Gert van den Berg** » Sat Jun 05, 2010 5:49 pm

Gert van den Berg wrote:
AS far as I know, the Linux version of Picasa does something like
this? (Not sure how its packaged)
Great I will have a look on my hopefully second example .

http://picasa.google.com/linux/download.html has some info...

Looks like a ~/.picasa is used... Not sure if it basically a .wine
(possibly with some links to save space....)

doh123 · Post by **doh123** » Sun Jun 06, 2010 11:41 am

I'm not a Linux expert.. but couldn't you bundle it up, and have scripts go to the right locations... much like I do with Wineskin for OSX. I have no problems with a single install of Wine and an app installed in it being moved from computer to computer with different user names working fine.... but this may be due to differences in OSX... I haven't seen anyone make something like that for Linux, but it seems like just symlinks and proper launch scripts would work fine.

Gert van den Berg · Post by **Gert van den Berg** » Sun Jun 06, 2010 12:19 pm

On Sun, Jun 6, 2010 at 18:41, doh123 <[email protected]> wrote:

I'm not a Linux expert.. but couldn't you bundle it up, and have scripts go to the right locations... much like I do with Wineskin (http://wineskin.doh123.com/) for OSX. Â I have no problems with a single install of Wine and an app installed in it being moved from computer to computer with different user names working fine.... but this may be due to differences in OSX... I haven't seen anyone make something like that for Linux, but it seems like just symlinks and proper launch scripts would work fine.

Between distributions libraries often (used to?) differ, needing at
least a relink to work... (Within the same distribution, packages
ussually work fine... And methods to get protable binaries exist...)

It shouldn't be affected by path, username, etc...

(On Picasa: it has a .wine under .google/picasa/3.0 with symlinks for
the Picasa EXEs (probably to save space). It seem to be using a
(potentially standard?) Wine 1.1.7)

Gert

liberavia · Post by **liberavia** » Sun Jun 06, 2010 1:40 pm

Well fine discussion round is open now

My example, which i studied a bit is the teamviewer deb.

So I can say if you have teamviewer installed, a startscript creates a file /home/your_home/.teamviewer/ (if not done yet). There you find all nessassary linking against the whole wine-instance in opt. Wine-Registry is copied to .teamviewer not linkes.

I had a really short look on the picasa deb but it seems to work the same way as teamviewer does.

I'm not a Linux expert.. but couldn't you bundle it up, and have scripts go to the right locations... much like I do with Wineskin for OSX. I have no problems with a single install of Wine and an app installed in it being moved from computer to computer with different user names working fine.... but this may be due to differences in OSX... I haven't seen anyone make something like that for Linux, but it seems like just symlinks and proper launch scripts would work fine.

yes this is what i want to reach for linux machines

a scripting framework which can create a bundle of wine + app or a least i guide how to get things work like in teamviewer or picasa.

Thats why I first posted at the playonlinux board because they seem be able to handle different wine-installations and assign different programs to different wine versions.

So I thought that playonlinux and its scripts could be a good base for creating bundled debs. Unfortunatly there is no post-reply at the moment. So I'm really glad that I found someone to discuss this topic

I figured out a problem which i feel unable to solve. It's the stand-alone wine(-server) installation. How can I build multiple side-by-side working installations of wine?

Teamviewer does it like this before wineserver instance is started:

Code: Select all

export WINELOADER=/path/to/wine/in/opt
export WINESERVER=/path/to/wineserver/in/opt

before he starts the instance and this is how he starts it

Code: Select all

if [ "$1" = "wineserver" ]
then
	shift
	exec "${WINESERVER:-wineserver}" "$@" 
else
	exec "${WINELOADER:-wine}" "$exe" "$@" 
fi

true

You will even find a killscript which i didn't figure out when this is called. Perhaps one of you? I just can make the guess, that you have a look on your own how things are wrapped for this package.

As I said before, I really would like to know how to get a stand-alone wine instance working, without the need of a system-wide installation, compilation stuff?

Hope someone can assist me with that.

Regards

André [/code]

Gert van den Berg · Post by **Gert van den Berg** » Sun Jun 06, 2010 4:51 pm

On Sun, Jun 6, 2010 at 20:40, liberavia wrote:

I figured out a problem which i feel unable to solve. It's the stand-alone wine(-server) installation. How can I build multiple side-by-side working installations of wine?

Compile it, set --prefix parameter for configure script to install it
somewhere unusual...

You might want to check if Teamviewer / Picasa have the relevant
source code (and possibly packaging scripts) available...

There is tools to view other processes' environments... (pargs -e
under Solaris, not sure about Linux)

On Sun, Jun 6, 2010 at 20:40, liberavia wrote:

So I can say if you have teamviewer installed, a startscript creates a file /home/your_home/.teamviewer/ (if not done yet). There you find all nessassary linking against the whole wine-instance in opt. Wine-Registry is copied to .teamviewer not linkes.

More Picasa details - symlinks present:

The .google directory is not linked. Most of the things in program files is....

mohag@mohagpc:~/.google$ find -type l | while read file; do ls -ldh
"$file"; done
lrwxrwxrwx 1 mohag mohag 39 2010-06-06 00:56
./picasa/3.0/dosdevices/c: -> /home/mohag/.google/picasa/3.0/drive_c/
lrwxrwxrwx 1 mohag mohag 1 2010-06-06 00:56 ./picasa/3.0/dosdevices/z: -> /
lrwxrwxrwx 1 mohag mohag 19 2010-06-06 00:56
./picasa/3.0/drive_c/Documents and Settings/mohag/Desktop ->
/home/mohag/Desktop
lrwxrwxrwx 1 mohag mohag 60 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/wine_gecko ->
/opt/google/picasa/3.0/wine/drive_c/Program Files/wine_gecko
lrwxrwxrwx 1 mohag mohag 69 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/i18n ->
/opt/google/picasa/3.0/wine/drive_c/Program Files/Google/Picasa3/i18n
lrwxrwxrwx 1 mohag mohag 72 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/buttons ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/buttons
lrwxrwxrwx 1 mohag mohag 68 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/web ->
/opt/google/picasa/3.0/wine/drive_c/Program Files/Google/Picasa3/web
lrwxrwxrwx 1 mohag mohag 78 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/Uninstall.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/Uninstall.exe
lrwxrwxrwx 1 mohag mohag 72 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/plugins ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/plugins
lrwxrwxrwx 1 mohag mohag 71 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/update ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/update
lrwxrwxrwx 1 mohag mohag 76 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/Picasa3.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/Picasa3.exe
lrwxrwxrwx 1 mohag mohag 78 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/qtsupport.dll ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/qtsupport.dll
lrwxrwxrwx 1 mohag mohag 79 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/moviethumb.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/moviethumb.exe
lrwxrwxrwx 1 mohag mohag 74 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/cdautorun ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/cdautorun
lrwxrwxrwx 1 mohag mohag 72 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/runtime ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/runtime
lrwxrwxrwx 1 mohag mohag 82 2010-06-06 00:56
./picasa/3.0/drive_c/Program Files/Google/Picasa3/PicasaUpdater.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/PicasaUpdater.exe
lrwxrwxrwx 1 mohag mohag 89 2010-06-06 00:56
./picasa/3.0/drive_c/Program
Files/Google/Picasa3/GoogleUpdaterService.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/GoogleUpdaterService.exe
lrwxrwxrwx 1 mohag mohag 86 2010-06-06 00:56
./picasa/3.0/drive_c/Program
Files/Google/Picasa3/PicasaPhotoViewer.exe ->
/opt/google/picasa/3.0/wine/drive_c/Program
Files/Google/Picasa3/PicasaPhotoViewer.exe
lrwxrwxrwx 1 mohag mohag 91 2010-06-06 00:56
./picasa/3.0/drive_c/windows/profiles/All Users/Start
Menu/Programs/Picasa 3 ->
/opt/google/picasa/3.0/wine/drive_c/windows/profiles/All Users/Start
Menu/Programs/Picasa 3
lrwxrwxrwx 1 mohag mohag 49 2010-06-06 00:56
./picasa/3.0/drive_c/windows/fonts ->
/opt/google/picasa/3.0/wine/drive_c/windows/fonts
lrwxrwxrwx 1 mohag mohag 47 2010-06-06 00:56
./picasa/3.0/drive_c/windows/inf ->
/opt/google/picasa/3.0/wine/drive_c/windows/inf
lrwxrwxrwx 1 mohag mohag 39 2010-06-06 00:56 ./picasa/3.0/generic.ppd
-> /opt/google/picasa/3.0/wine/generic.ppd

Whithil XBR · Post by **Whithil XBR** » Wed Oct 17, 2012 9:16 am

Rise from your graves, let's finish this old topic!

It's a great idea, but what happened?

Whithil XBR · Post by **Whithil XBR** » Wed Oct 17, 2012 9:29 am

I'm wondering...

Why not just create a wine deb with different prefix (.appname instead of .wine) and extract a pre-configured wineprefix to ".appname"?
something like the "PlayOnLinux Vault" plugin for PlayOnLinux wich can package an entire wineprefix so it can be used in other computer.

Just needs some adjustments to avoid conflicts with a "true wine" right?

Post by **DanKegel** » Wed Oct 17, 2012 6:00 pm

Yep.

It's a fine idea. I've done it several times at my day job. So, which app needs this treatment the most?

Is there some really popular open source app without a Linux port that could go into Ubuntu's software center?

Whithil XBR · Post by **Whithil XBR** » Thu Oct 18, 2012 8:05 am

DanKegel wrote:Yep.

It's a fine idea. I've done it several times at my day job. So, which app needs this treatment the most?

Is there some really popular open source app without a Linux port that could go into Ubuntu's software center?

Well, maybe if something was developed to package Windows apps with wine...

But there are 2 questions to answer first:

1 - Can we just use wine's code in another project?
2 - Proprietary software can't be repackaged (except by it's owner), right?

Whithil XBR · Post by **Whithil XBR** » Thu Oct 18, 2012 8:16 am

I'm completely noob... But maybe I could try Python, shell script, some variables for the package name...
Boring but I believe this could work

What about "Sommelier" ? hehe nice name.