wine users - Jun 2010 - migrating windows applications by packing wine+app in a deb?

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-3536-wine_applications_as_a_deb_like_teamviewer.html

Regards

Andr?

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.

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

I got an answer :D


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.

[quote="oiaohm"]
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 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....)

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.

Well fine discussion round is open now :D

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:
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:
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]