Hello to everyone,
After I posted in the wrong board, I moved my post here. where i guess its fitting better. Sorry for that mistake.
I'm new so first I should introduce myself:
My name is André from Berlin and I'm using Linux as my prefered system since 2004. I'm a developer and some of my reduced spare time I'm trying out new things or focus new Ideas for the system of my choice. The ability to do this is, i guess, the predominating reason why I use Linux ;-)
Periodicly I came in contact with wine (Actually I'm one of those who bought a winex cd for suse 9.0 to be able to play diablo II :laught: ). Nowadays wine has gone really far and well implemented in most distros. I first heard about PlayOnLinux a few months ago and I want to say thank to all supporters of that project.
Using wineprefixes in a way pol uses it, is the right way to handle version incompatibilities.
The need of wine in general is obvious in my opinion and even it doesn't solve problems by the root, it's the best working solution to get popular and demanded applications run.
To topic:
Have you heard from the Teamviewer (a popular zero conf remote desktop application) port for linux? It's a wine solution packed in a deb-package.
As I heard about this, I was very curious to know how they get this thing work. So I unpacked the deb and took a look on the content.
I found out the following:
1. The whole program and wine logic lies in opt/teamviewer/teamviewer/5
2. A symlink is created in usr/bin which points to the startscript teamviewer in opt/teamviewer/teamviewer/5/bin/
3. this script creates a variable to teamviewers binaries and starts the script wrapper in the same directory.
4. The wrapper script handles the execution flow using the wine-installation in opt which is delivered by the package. It contains a bash function, which creates the nessassary file structure in users home if not already done. The delivered wine version can be found in opt/teamviewer/teamviewer/5/wine.
There is also a postinst script which creates the menu-entry with also deb-delivered xdg-utils.
I thought by myself that this is really clever. Why don't use this method for other programs? Currently I have such an application(group), which works really fine in wine 1.0.1 using winetricks (gdi-plus and ie6). I created live-cds with this application pre-installed but I would prefer to create a deb like teamviewer does it. From time to time I'm in exchange with one of the developers of the application, who is also a linux-friend himself. He was glad, that I began experementing, because he also wanted to try out if the app will run on linux, but never had the time to do so.
While I was thinking about how to generate a guide or a script which creates deb-packages of wine-based applications, he told me that he is going to use some Linux-Based installations of the app in his company. He suggested to write a PlayOnLinux-Script.
At this point I started to think about PlayOnLinux's possibilities to be the app to be able to create debs because of it's knowledge of certain applications and the way it handles them (Which wine version? Which libraries? etc. ) .
Edit: Until now I didn't get things work like in teamviewer, which is also caused by my very reduced spare time, but they show us that it can work.
- What is nessessary to generate a stand-alone working wineserver ?
- Is it rock-solid enough to run multiple instances of wine(-server) ?
- What do you think about the idea of creating deb-packages of wine applications each including its own wineserver?
- Could PlayOnLinux the "creator-app" for creating the mentioned deb-packages?
- If we think further: How could it be possible to handle big applications > 200 MB?
- And if it works: Shouldn't there be a repository for those apps?
Thanks for your interest.
I'm keen to hear about your opinion to this topic :-)
Regards
André
P. S. Text has been reedited in the meantime
Edité par liberavia
