Hallo allerseits,

Vorab: Ich weiß, das ist ein heikles Thema und im Prinzip auch nicht wünschenswert, da es ja nun nicht zu viel von Herstellern einer Software verlangt wäre, plattformunabhängig zu proggen 🙄

Nun ist die Welt aber eine andere und ich möchte ein deb-Paket für ein Windows-Programm, welches soweit einwandfrei unter wine läuft, erstellen. Bisher habe ich hierfür Live-Distris mittels UCK zusammengestrickt, wo /etc/skel bereits alles zur Anwendung enthielt (inklusive zwei winetricks) was notwendig ist. Dazu habe ich dann ein zentrales startscript abgelegt, so dass jeder User das Programm/Die Programmgruppe über das Gnome Menü starten kann. (Für den interessierten: http://forum.ubuntuusers.de/topic/global-gueltige-wine-verknuefungen-im-gnome-m/#post-2424924 )

Das Entdecken und verbessern kleinerer Fehler ist wie ihr euch sicher vorstellen könnt sehr Zeitaufwendig und kann wiederum zu neuen Fehlern und neuen Builds führen etc. Lieber würde ich ein Deb-Paket bauen, welches die wine-Anwendung "zentral" zugänglich macht.

Darauf gebracht hat mich die Meldung der Linux-Teamviewer-Version, welche ja bekanntermaßen eine für wine modifizierte Version des Windowsprogramms ist.

Folglich hat mich natürlich brennend interessiert, wie die Mädels und Jungs bei TeamViewer das realisiert haben. Also habe ich mir das DEB-Paket des Teamviewers geschnappt, entpackt und näher angeschaut und folgendes tritt für mich zu Tage:

1. Die gesamte Programm/Wrapper-Funktionalität liegt im Ordner opt/teamviewer/teamviewer/5

2. Im Ordner usr/bin wird ein symlink angelegt, welcher auf das startscript teamviewer in opt/teamviewer/teamviewer/5/bin/ zeigt

3. Dieses Script legt das Binärverzeichnis für teamviewer fest und startet seinerseits das script wrapper im selben Verzeichnis

4. wrapper ist das Script welches die zentrale Ausführung der unter opt liegenden wine-Installation ermöglicht. Es enthält eine Bash-Funktion, welche die nötige Verzeichnis-Strukturen beim aktuellen Nutzerverzeichnis anlegt, denn das Paket installiert nicht die wine-Version aus den Quellen als Paketabhängigkeit, sondern liefert eine eigene Version von wine unter opt/teamviewer/teamviewer/5/wine mit.

Natürlich gibt es auch preinst-Scripte, die ich mir allerdings auf die Schnelle nicht angeschaut habe.

Eigentlich eine ganz clevere Herangehensweise. Wenn das Paket schon nicht nativ vorliegt, so wird durch die mitgelieferte wine version sichergestellt, dass das Win-Prog auch ohne eine vorherige wine-installation läuft bzw. nicht durch unvorhersehbare updates nicht mehr funktioniert.

Nun zurück zu meinem Thema: Gerne würde ich das genauso handhaben, wie teamviewer das gelöst hat, bin mir aber noch nicht ganz im klaren wie ich das am besten anstellen soll. Meine Fragen:

1. Als Basis habe ich die wine-Struktur Meiner angepassten Distri, kann ich diese im prinzip übernehmen bzw. worauf sollte ich dabei achten?

2. Wäre es zum Beispiel ratsam durch ein AppArmor Profil zusätzliche Barrieren einzubauen, da es sich ja dann um ein win-Programm handelt welches plötzlich außerhalb des vorgesehenen Benutzerverzeichnisses agiert?

3. Teamviewer hat ein seperates Kill-Script, wofür ist mir aber noch ein wenig schleierhaft (opt/teamviewer/teamviewer/5/bin/killteamviewer)

4. Und zuguterletzt: Wie seht ihr diese Möglichkeit für wine-Programme?

Wenn nichts dagegen spricht, würde ich aus der Herangehensweise Teamviewer am liebsten ein kleines Guide herausbekommen, wie man es schaffen kann wine-Programme zentral verfügbar zu machen.

Vielen Dank für euer Interesse ☺

Habe gerade nicht viel Zeit, ein paar Sachen will ich aber schnell anmerken, mehr dann hoffentlich am Wochenende. Ist nen interessantes Thema das du da ansprichst 😀

liberavia schrieb:

1. Als Basis habe ich die wine-Struktur Meiner angepassten Distri, kann ich diese im prinzip übernehmen bzw. worauf sollte ich dabei achten?

Sollte theoretisch möglich sein, wenn bestimmte Sachen gegeben sind, siehe unten.

1. Wäre es zum Beispiel ratsam durch ein AppArmor Profil zusätzliche Barrieren einzubauen, da es sich ja dann um ein win-Programm handelt welches plötzlich außerhalb des vorgesehenen Benutzerverzeichnisses agiert?

Nein, es sei denn du startest das Programm als root. Wenn du es als normaler Nutzer startest hat es nur da Schreibrechte wo du sie auch hast: Bei dir im /home. Solche Programme unter anderen Pfaden als .wine/ zu installieren ist daher warscheinlich auch nicht so geschickt, da es evtl. Schreibrechte in seinem Programmordner vorraussetzt die es dann aber nicht hat.

1. Teamviewer hat ein seperates Kill-Script, wofür ist mir aber noch ein wenig schleierhaft (opt/teamviewer/teamviewer/5/bin/killteamviewer)

2. Und zuguterletzt: Wie seht ihr diese Möglichkeit für wine-Programme?

Wenn nichts dagegen spricht, würde ich aus der Herangehensweise Teamviewer am liebsten ein kleines Guide herausbekommen, wie man es schaffen kann wine-Programme zentral verfügbar zu machen.

Insbesondere aufpassen würde ich mit der Lizenzsituation. Wenn es ein unter einer Freien Lizenz stehendes Projekt ist hast du kein Problem, sobald es aber ein Proprietäres (Auch Freeware)-Produkt ist: Keine Chance ausser mit Erlaubnis des Rechteinhabers.

Hefeweiz3n schrieb:

Habe gerade nicht viel Zeit, ein paar Sachen will ich aber schnell anmerken, mehr dann hoffentlich am Wochenende. Ist nen interessantes Thema das du da ansprichst 😀

Find ich nämlich auch 😉 Und das mit der Zeit ist bei mir grad dasselbe, daher auch jetzt kurz und nachher mehr ☺

Nein, es sei denn du startest das Programm als root. Wenn du es als normaler Nutzer startest hat es nur da Schreibrechte wo du sie auch hast: Bei dir im /home. Solche Programme unter anderen Pfaden als .wine/ zu installieren ist daher warscheinlich auch nicht so geschickt, da es evtl. Schreibrechte in seinem Programmordner vorraussetzt die es dann aber nicht hat.

Und da ist es interessant, wie teamviewer das handhabt. Teamviewer installiert im Home-Verzeichnis ein Verzeichnis .teamviewer. In diesem ist auche eine wine-Struktur abgelegt, in der symlinks zu opt gelegt sind. Somit ist wohl die Schreibproblematik umgangen. Dieses Verfahren mit Symlinks habe ich zum Thema zentrale wine Anwendungen schon mal als Vorschlag in anderen Posts gelesen

Insbesondere aufpassen würde ich mit der Lizenzsituation. Wenn es ein unter einer Freien Lizenz stehendes Projekt ist hast du kein Problem, sobald es aber ein Proprietäres (Auch Freeware)-Produkt ist: Keine Chance ausser mit Erlaubnis des Rechteinhabers.

Mich interessiert ja nicht die Anwendung selber, sondern die Funktionalität der Bash-Scripte, die die Ausführung einer Linux-Anwendung simulieren. Ob diese rechtlich behaftet sind, kann ich derzeit nicht sagen. Ich habe ja auch nicht vor einfach copy-paste zu betreiben. Aber verstehen will ich die Vorgehensweise von Teasmviewer für Linux um das auf andere in Wine funktionierende Anwendungen zu übertragen.

So weit erstmal.

Für alle interessierten lohnt es sich definitiv mal das deb von teamviewer zu entpacken und einen Blick zu riskieren 😉 Besonders interessant ist die setup_wine Funktion des scripts wrapper. Auch das postinst-script bringt IMHO ein wenig Aufschluss.

Bis denne

Edit:

Zum Rechtlichen steht in der Lizenz folgendes:

Es ist dem Anwender nicht gestattet, Produktkennzeichnungen, Copyright-Hinweise

oder andere Hinweise zu entfernen oder modifizieren.

Es ist nicht gestattet, die Software dem Reverse Engineering, der Disassemblierung

oder der Decompilierung zu unterziehen.

Da ich mir lediglich die Start-Scripte und die Art und Weise der wine-Integration anschaue, fühle ich mich eigentlich auf der sicheren Seite.

Auch wenn natürlich obligatorisch folgendes in den Copyright-Vermerken steht:

COPYRIGHT/URHEBERRECHTE

TeamViewer ist ausschließliches Eigentum der TeamViewer GmbH und

Durch internationales Urheberrecht geschützt.

Kunden erwerben lediglich das Recht, die Software im hier angegebenen Umfang zu

nutzen, es wird keinerlei Recht an der Software selbst oder an TeamViewer

erworben.

Auch wenn in den Bash Scripten nix lizenzrechtliches zu finden ist, sollte ich wohl vorsichtshalber bei Teamviewer anfragen, oder?

Edit 2:

Habe an Teamviewer eine Mail geschickt in der ich angefragt habe, wie das mit den Shell-Scripten aussieht. Eigentlich sollte das ja kein Problem sein, da ich ja nicht den Code kopieren will, sondern mich für die Art und Weise der Portierung mit einer für die Windowsanwendung mitgelieferten wine-Version interessiere.

Wie seht ihr das?

Ok, die kurze Antwort aus der Entwicklungsabteilung der Teamviewer GmbH bezüglich der Shell Scripte:

[...] Kopieren dürfen Sie die Skripte zwar nicht, die eine oder andere Idee daraus können Sie sich aber gern nehmen [...]

Demnach werde ich dann demnächst mal probieren die Windows Anwendung, um die es bei mir geht, so zu verpacken, dass auch diese mit einer eigenen wine-Instanz geliefert wird, die unabhängig von einer wine-Installation läuft.

Allerdings sitze ich in meinem Urlaub paralell dazu noch meiner Telefonanlagenlösung callbuntu-webgui, also kann das noch ein wenig dauern, bis ich meinen Versuch ausprobieren kann.

Mein Vorschlag an alle Interessierten lautet also:

Wenn ihr eine Windows-Anwendung zur Hand habt, die hervorragend mit wine x.y funktioniert, versucht doch einfach mal am Vorbild von Teamviewer ein deb dieser Windows-Anwendung zu erstellen. Erkenntnisse, Fehlschläge und natürlich auch Tipps und Erfolgsmeldungen können dann in diesem Thread gepostet werden. So werde ich das zumindest handhaben.

Zielstellung sollte IMHO ein Guide zur Erstellung von Debian-Paketen für Windows-Anwendungen sein, dessen Grundlage wir hier legen.

Hoffentlich bin ich nicht der einzige Interessierte 😉

Schöne Grüße

Ich schließ den Thread als gelöst. In der Zwischenzeit gibt es konkrete Scripte, welche versuchen einen zentralen Weg mit Wineprefixen zu gehen. Die Einzelheiten diskutiere ich in folgendem Thread: http://forum.ubuntuusers.de/topic/z-b-wine-notepad-als-debian-paket/