staging.inyokaproject.org

Hi there,

dieser Post baut auf einem älteren von mir auf: http://forum.ubuntuusers.de/topic/wine-applikationen-als-deb-am-beispiel-von-te/

Das Thema hat mich nie so richtig verlassen und daher hatte ich vor geraumer Zeit mal ein paar Scripte ausprobiert, die ich hier mit euch teilen und verbessern möchte. Im Prinzip, bin ich fast der Meinung, das man das mit Python besser lösen könnte als mit der bash.

Aufgabe:

Es geht darum einen wineprefix an einen zentralen Ort wie /opt/ zu hinterlegen. Ein Startscript für die Wine-Applikation sorgt dafür, dass im Home-Folder dieselbe Struktur vorliegt. Dateien und Verzeichnisse, welche die Wine-Applikation zum schreiben benötigt oder userspezisische Savegames und Konfigurationsdateien, liegen dabei im Home-Folder physisch vor. Jegliche unveränderliche Dateien werden per Symlink aus /opt/ mit dem Home-Folder verknüpft. Am Ende steht im Home-Folder-Prefix also die komplette Struktur des Wineprefixes inkl. notwendiger schreibrechte. Die Anwendung selber bzw. der Wine-Prefix liegt zentral in /opt/. Die passende Wine-Version liegt ebenfalls zentral. Das Script bindet Wine-Version und Prefix zusammen.

Hat man eine solche funktionierende Struktur, so ist der Weg zu einem Debian-Paket nicht mehr fern. Patches könnten somit für alle zentral über apt-einfließen. Sowohl an wineprefix als auch die wineversion, die genauso passend upgegradet werden könnte. Die Installation über apt brächte noch den Vorteil bestimmte Dialoge zentral erfolgen zu lassen, wie z. B. Zustimmung zu einer Lizenz etc.

Lösungsansatz:

Bevor ich die Scripte poste, folgt hier eine kleine Erläuterung der Herangehensweise an die Lösung der Aufgabe:

• Basis bildet eine mittels PlayOnLinux erstellte Installation eines Programms.

• Der Wineprefix und die WineVersion werden in eine entsprechende Struktur in /opt/ überführt. In meinem Fall nach folgendem Muster /opt/wineports/<HerstellerDir>/<Programm-Dir>/ . Hierunter werden die Verzeichnisse wine und wineprefix angelegt.

• Ein Startscript kümmert sich beim Start ggf. um die Einrichtung einer entsprechenden Home-Folder-Struktur, welche die /opt/ Struktur mittels Symlinks verknüft und schreibbare Verzeichnisse im Home-Folder physisch anlegt.

• Die entsprechende Wine-Ausführung und der zugehörige Wineprefix werden in die Umgebungsvariablen geschrieben.

• Das Programm wird gestartet.

Beispiel 1 wpstartnpp.sh:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

#!/bin/bash

# set basic opt path of application
PROG_OPT_DIR="/opt/wineports/NotepadplusplusTeam/Notepadplusplus"
PROG_HOME_DIR="$HOME/.wineports/NotepadplusplusTeam/Notepadplusplus"
PROG_WINE_DIR="$PROG_OPT_DIR/wine"
PROG_WINE_BIN="$PROG_WINE_DIR/bin"

# set base environment variables
export PATH=$PROG_WINE_BIN:$PATH
export LD_LIBRARY_PATH=$PROG_WINE_DIR/lib:$PROG_WINE_DIR/lib/fakedlls:$LD_LIBRARY_PATH
export WINEPREFIX="$PROG_HOME_DIR/prefix"
export WINEDLLPATH="$PROG_WINE_DIR/lib/wine"
export WINELOADER="$PROG_WINE_BIN/wine"
export WINESERVER="$PROG_WINE_BIN/wineserver"
export PREFIX_PROG_DIR="$WINEPREFIX/drive_c/ProgramFiles/Notepad++/"
export OPT_PROG_DIR="$PROG_OPT_DIR/prefix/drive_c/ProgramFiles/Notepad++/"
export OPT_SEARCH_DIR=$PROG_OPT_DIR/prefix/drive_c/ProgramFiles/Notepad++/
export WINEPORTS_MAXDEPTH_SEARCH=5
export WINEPORTS_DOS_STARTPATH="c:\ProgramFiles\Notepad++\notepad++.exe"
# export WINEPORTS_SHARE_FOLDER="/usr/share/wineports/PiranhaBytes/Gothic/"


function SetupHomeEnvironment()
{
  # create symlinks for dosdevices
  mkdir -p $WINEPREFIX/dosdevices/
  local C_LINK="$WINEPREFIX/dosdevices/c:"
  local C_TARGET="$WINEPREFIX/drive_c/"
  local Z_LINK="$WINEPREFIX/dosdevices/z:"
  local Z_TARGET="/"
  ln -s $C_TARGET $C_LINK
  ln -s $Z_TARGET $Z_LINK
  
  # create basic home folder for placing all symlink-elements in  
  if ! [ -d "$PREFIX_PROG_DIR" ] ; then
    mkdir -p "$PREFIX_PROG_DIR" 
  fi
  
  # search source dir for all folders and subfolders in configured depth
  # @TODO: Search delivers too much results in subfolders
  EMPTY_REPLACEMENT=""
echo $OPT_SEARCH_DIR
echo "find $OPT_SEARCH_DIR -maxdepth $WINEPORTS_MAXDEPTH_SEARCH -type d -print0 -printf \"%h;\""
  RecursivePathSearch="$(find $OPT_SEARCH_DIR -maxdepth $WINEPORTS_MAXDEPTH_SEARCH -type d -print0 -printf "%h;")"
echo $RecursivePathSearch
  OrigIFS=$IFS
  IFS=";"
  ArrayPathSearch=($RecursivePathSearch)
# echo ${ArrayPathSearch[@]}
exit 0

  COUNTER=0
  for CurrentPath in ${ArrayPathSearch[@]} ; do
    if ! [ -e "$CurrentPath" ] ; then
      if [ "$COUNTER" != "0" ] ; then
        # remove opt-path
	RelativePath="${CurrentPath//$OPT_PROG_DIR/$EMPTY_REPLACEMENT}"
	# Switched off escaping due it does not create exprected results
	# EscapedRelativePath=$(echo $RelativePath | sed 's/ /\\ /g')
	CreateHomePath "$RelativePath"
	LinkSubpath "$RelativePath"
      fi
      let COUNTER=COUNTER+1
    fi
  done

  IFS=$OrigIFS    
}

function LinkSubpath() {
  local SubOptPath="$OPT_PROG_DIR$1"
  local SubHomePath="$PREFIX_PROG_DIR$1"
echo $SubOptPath
  # search files in opt path if opt-path exists and link home links to corresponding opt-files
  if [ -e "$SubOptPath" ] ; then
    # echo "find $SubOptPath -maxdepth 1 -type f \( ! -iname \".*\" \) \( ! -iname \"*~\" \) -printf \"%f;\""
    FileSearchResult=$(find $SubOptPath -maxdepth 1 -type f \( ! -iname ".*" \) \( ! -iname "*~" \) -printf "%f;")
    # echo $FileSearchResult
    OrigIFS=$IFS
    IFS=";"
    ArrayFileSearch=($FileSearchResult)
    COUNTER=0
    for CurrentFile in ${ArrayFileSearch[@]} ; do
	if ! [ -e "$SubHomePath/$CurrentFile" ] ; then
	  echo "ln -s $SubOptPath/$CurrentFile $SubHomePath/$CurrentFile"
	  ln -s $SubOptPath/$CurrentFile $SubHomePath/$CurrentFile
	fi
    done  
    IFS=$OrigIFS
  fi
}

function CreateHomePath() {
  local CreatePath="$PREFIX_PROG_DIR$1"
  if ! [ -d "$CreatePath" ] ; then 
    echo "mkdir -p $CreatePath"
    mkdir -p $CreatePath
  fi
}

function CreatePath() {
  local CreatePath="$1"
  if ! [ -d "$CreatePath" ] ; then 
    mkdir -p $CreatePath
  fi
}

function CopyConfig() {
  echo "Copy ini files from share to home folder"
}

function RunApplication() {
  winedbg $WINEPORTS_DOS_STARTPATH
}



CreatePath "$PROG_HOME_DIR"
CreatePath "$WINEPREFIX"

SetupHomeEnvironment
RunApplication

Beispiel 2 wpstartgothic.sh:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

#!/bin/bash

# set basic opt path of application
PROG_OPT_DIR="/opt/wineports/PiranhaBytes/Gothic"
PROG_HOME_DIR="$HOME/.wineports/PiranhaBytes/Gothic"
PROG_WINE_DIR="$PROG_OPT_DIR/wine"
PROG_WINE_BIN="$PROG_WINE_DIR/bin"

# set base environment variables
export PATH=$PROG_WINE_BIN:$PATH
export LD_LIBRARY_PATH=$PROG_WINE_DIR/lib:$PROG_WINE_DIR/lib/fakedlls:$LD_LIBRARY_PATH
export WINEPREFIX="$PROG_HOME_DIR/prefix"
export WINEDLLPATH="$PROG_WINE_DIR/lib/wine"
export WINELOADER="$PROG_WINE_BIN/wine"
export WINESERVER="$PROG_WINE_BIN/wineserver"
export PREFIX_PROG_DIR="$WINEPREFIX/drive_c/Programme/PiranhaBytes/Gothic"
export OPT_PROG_DIR="$PROG_OPT_DIR/prefix/drive_c/Programme/PiranhaBytes/Gothic"
export WINEPORTS_MAXDEPTH_SEARCH=5
export WINEPORTS_DOS_STARTPATH="c:\Programme\PiranhaBytes\Gothic\system\gothic.exe"
export WINEPORTS_SHARE_FOLDER="/usr/share/wineports/PiranhaBytes/Gothic/"


function SetupHomeEnvironment()
{
  # create symlinks for dosdevices
  mkdir -p $WINEPREFIX/dosdevices/
  local C_LINK="$WINEPREFIX/dosdevices/c:"
  local C_TARGET="$WINEPREFIX/drive_c/"
  local Z_LINK="$WINEPREFIX/dosdevices/z:"
  local Z_TARGET="/"
  #local D_LINK="$WINEPREFIX/dosdevices/d:"
  #local D_TARGET="/media/GOTHIC_CD2/"
  ln -s $C_TARGET $C_LINK
  ln -s $Z_TARGET $Z_LINK
  #ln -s $D_TARGET $D_LINK
  
  # create basic home folder for placing all symlink-elements in  
  if ! [ -d "$PREFIX_PROG_DIR" ] ; then
    mkdir -p "$PREFIX_PROG_DIR" 
  fi
  
  # search source dir for all folders and subfolders in configured depth
  # @TODO: Search delivers too much results in subfolders
  EMPTY_REPLACEMENT=""
  RecursivePathSearch="$(find $OPT_PROG_DIR -maxdepth $WINEPORTS_MAXDEPTH_SEARCH -type d -print0 -printf "%h;")"

  OrigIFS=$IFS
  IFS=";"
  ArrayPathSearch=($RecursivePathSearch)

  COUNTER=0
  
  for CurrentPath in ${ArrayPathSearch[@]} ; do
    if ! [ -e "$CurrentPath" ] ; then
      if [ "$COUNTER" != "0" ] ; then
        # remove opt-path
	RelativePath="${CurrentPath//$OPT_PROG_DIR/$EMPTY_REPLACEMENT}"
	# Switched off escaping due it does not create exprected results
	# EscapedRelativePath=$(echo $RelativePath | sed 's/ /\\ /g')
	CreateHomePath "$RelativePath"
	LinkSubpath "$RelativePath"
      fi
      let COUNTER=COUNTER+1
    fi
  done

  IFS=$OrigIFS    
}

function LinkSubpath() {
  local SubOptPath="$OPT_PROG_DIR$1"
  local SubHomePath="$PREFIX_PROG_DIR$1"
  
  # search files in opt path if opt-path exists and link home links to corresponding opt-files
  if [ -e "$SubOptPath" ] ; then
    # echo "find $SubOptPath -maxdepth 1 -type f \( ! -iname \".*\" \) \( ! -iname \"*~\" \) -printf \"%f;\""
    FileSearchResult=$(find $SubOptPath -maxdepth 1 -type f \( ! -iname ".*" \) \( ! -iname "*~" \) -printf "%f;")
    # echo $FileSearchResult
    OrigIFS=$IFS
    IFS=";"
    ArrayFileSearch=($FileSearchResult)
    COUNTER=0
    for CurrentFile in ${ArrayFileSearch[@]} ; do
	if ! [ -e "$SubHomePath/$CurrentFile" ] ; then
	  ln -s $SubOptPath/$CurrentFile $SubHomePath/$CurrentFile
	fi
    done  
    IFS=$OrigIFS
  fi
}

function CreateHomePath() {
  local CreatePath="$PREFIX_PROG_DIR$1"
  if ! [ -d "$CreatePath" ] ; then 
    mkdir -p $CreatePath
  fi
}

function CreatePath() {
  local CreatePath="$1"
  if ! [ -d "$CreatePath" ] ; then 
    mkdir -p $CreatePath
  fi
}

function CopyConfig() {
  echo "Copy ini files from share to home folder"
}

function RunApplication() {
  winedbg $WINEPORTS_DOS_STARTPATH
}



CreatePath "$PROG_HOME_DIR"
CreatePath "$WINEPREFIX"

SetupHomeEnvironment
RunApplication

Der Aufbau ist recht identisch. Die beiden Scripte funktionieren bisher nicht vollständig. Dabei haben beide unterschiedliche Probleme. Dass notepad++-Startscript hat Probleme, die Verzeichnisse korrekt zu ermitteln und das Gothic-Startscript bricht am Ladebildschirm innerhalb von wine ab.

Verbesserungsmöglichkeiten:

Natürlich sind mir schon ein paar Gedanken gekommen, wie man den Ansatz verbessern könnte. Generell denke ich, dass man das ganze viel enger mit PlayOnLinux verzahnen sollte und mehr von der PlayOnLinux-Struktur Gebrauch machen. Also z. B. die Prefixe in der Homestruktur von POL verlinken. Und statt einer Wineversion in /opt/ lediglich die POL-Konfiguration so anzulegen, dass POL die passende Wine-Version prüft und ggf. herunterlädt.

Dass eine zentrale Wine-Installation prinzipiell funktioniert ist unbestritten ( Siehe Teamviewer ), jedoch würde ich mal gern einen generellen, gangbaren Weg ausarbeiten, mit welchem man zentrale Installationen von Wine-Basierter Software ermöglichen könnte.

Hoffe, dass das Thema jemanden von euch interessiert und ihr eure Gedanken und/oder Verbesserungsvorschläge mit mir teilt. Habt ihr vielleicht schon ähnliche Versuche unternommen? Welche sicherheitstechnischen Bedenken habt ihr bei der Symlink-Methode?

Gruß

André

Hi nochmal,

habe das ganze mittlerweile so umgeschrieben, dass ich versuche von der POL-Struktur gebrauch zu machen. Allerdings habe ich aktuell das Problem, dass meine in den Prefix gelinkte Anwendung nicht wirklich erkannt wird, was vermutlich an der Registry liegt. Es verhält sich wohl so, als wenn ich versuche die Programmdateien einfach in ein Windows zu kopieren, was ja seit DOS-Zeiten etwas anders läuft. Leider bin ich absolut kein Registry hacker und die Wine-Seite zur Registry hilft mir hier auch nur bedingt weiter. Ich würde gerne wissen, wie ich die Installation nachträglich sauber ins System integrieren kann. Die Dateien dazu sind jedenfalls vorhanden. Beim Debuggen erhalte ich folgende Meldung:

1
2

[09/21/13 21:38:50] - Running wine-1.7.2 psr.exe (Working directory : /home/andre/.PlayOnLinux)
wine: cannot find L"C:windowssystem32psr.exe"

Hier die ganze Diskussion, die ich dazu im POL-Forum begonnen habe:

http://www.playonlinux.com/en/topic-10962-centralized_wineprefix_as_preparation_for_debpackages.html

Meine Testanwendung ist in diesem Fall allerdings "Password Safe Repository" von Mateso, allerdings sollen die Scripte am Ende mittels Konfiguration universell einsetzbar sein. Hier die Scripte via sourceforge:

Start: https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/wineportstart.py

Klasse die vom Startscript verwendet wird: https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/pol_wineport_environment.py

POL-Script um den Prefix zu erstellen und die passende Wine-Version herunterzuladen: https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/CreatePrefixPasswordSafeRepository.sh

POL-Script um einen Shortcut zu erzeugen (tut derzeit nicht): https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/CreateShortcutPasswordSafeRepository.sh

Eintrag für die Liste der POL-Applikationen (Quick hack): https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/PasswortSafeRepository

Vieleicht kann jemand weiterhelfen meine (vermutlich) letzte grundlegende Hürde zu nehmen. Ich würd mich sehr freuen.

Gruß

André

Es hat geklappt !!! Yes !!! 😀

Nachdem ich mittels diff festgestellt hatte, welche Einträge in der system und user registry erzeugt werden, habe ich bemerkt, dass diese mit meiner vorgespeicherten Konfiguration bis auf den timestamp identisch waren. Schlussfolgerung: Es lag nicht nur an der Registry. Dann habe ich anhand des Fehlers nochmal recherchiert und bin dabei darauf gestoßen, dass das einfach daran liegt, dass man sich nicht im richtigen Verzeichnis befindet. Somit habe ich mir meinen Starter nochmal angeschaut und habe dann festgestellt, dass es einfach daran lag, dass ich Dussel einfach den falschen Pfad hinterlegt hatte 🙄

Nachdem ich diesen angepasst hatte, lief die Anwendung einwandfrei ☺

What's next?

1. Nun werde ich in meiner Testanwendung noch evaluieren, ob die Registry Einträge überhaupt eine Rolle Spielten. Sollte das der Fall sein, so werde ich einen Weg finden müssen wie das Userindividuell hinzugefügt werden kann.

2. Des weiteren werde ich meine Testawendung mit anderen Benutzerkonten prüfen.

3. Zum Schluss werde ich ein Debian Paket daraus bauen und von anderen Nutzern aus meinem Umfeld testen lassen.

4. Wenn das tut würde ich eine Anwendung veröfentlichen, bei der ich keine rechtlichen Konsequenzen fürchten muss (Aktuell notepad++). Vorschläge ür Windows-Anwendungen sind willkommen.

Gruß André

Kurzes Update:

1. Nun werde ich in meiner Testanwendung noch evaluieren, ob die Registry Einträge überhaupt eine Rolle Spielten. Sollte das der Fall sein, so werde ich einen Weg finden müssen wie das Userindividuell hinzugefügt werden kann.

Registry Einträge werden von meiner Beispielanwedung bei Start selbst angelegt.

2. Des weiteren werde ich meine Testawendung mit anderen Benutzerkonten prüfen.

Hat nach Anpassungen aus Revision 3 funktioniert ☺

http://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/

Heute mal das erste Testpaket gebaut und auf dem anderen Rechner ausprobiert. Abgesehen vom Typo in der Desktop-Datei und dem falschen Pfad zu applications, schien es erst gut zu funktionieren. Jedoch wurde an irgend einer Stelle der Home-Pfad umgestellt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

[POL_System_CheckFS] Message: Checking filesystem for psr.exe
[POL_Wine] Message: Running wine- psr.exe (Working directory : /home/ramona/.PlayOnLinux/wineprefix/PasswortSafeRepository/drive_c/Program Files/Password Safe and Repository 6)
/usr/share/playonlinux/lib/debug.lib: Zeile 220: /home/andre/.PlayOnLinux//wineprefix/PasswortSafeRepository/playonlinux.log: Datei oder Verzeichnis nicht gefunden
[POL_Wine] Message: Notice: PlayOnLinux deliberately disables winemenubuilder. See http://www.playonlinux.com/fr/page-26-Winemenubuilder.html
tee: /home/andre/.PlayOnLinux//wineprefix/PasswortSafeRepository/playonlinux.log: Datei oder Verzeichnis nicht gefunden
wine: chdir to /home/andre/.PlayOnLinux//wineprefix/PasswortSafeRepository
 : No such file or directory
tee: /home/andre/.PlayOnLinux//wineprefix/PasswortSafeRepository/playonlinux.log: Datei oder Verzeichnis nicht gefunden
[POL_Wine] Error: Wine scheint abgestürzt zu sein

Wenn Ihr Programm weiter läuft, ignorieren Sie diese Nachricht
[POL_SetupWindow_Init] Message: Creating new window for pid 9576
Killed
Falseramona@ramona-desktop:~$ cd /home/andre/.PlayOnLinux//wineprefix/
bash: cd: /home/andre/.PlayOnLinux//wineprefix/: Datei oder Verzeichnis nicht gefunden
ramona@ramona-desktop:~$ cd /home/andre/.PlayOnLinux/wineprefix/
bash: cd: /home/andre/.PlayOnLinux/wineprefix/: Datei oder Verzeichnis nicht gefunden

Mal schauen wo das herkommt.

3. Zum Schluss werde ich ein Debian Paket daraus bauen und von anderen Nutzern aus meinem Umfeld testen lassen.

Debian Paket(e) ist/sind gebaut und ich habe das Programm erfolgreich auf einem anderen Rechner installieren und ausführen können. Passende Wine-Versionen und Paketabhängigkeiten werden beim ersten Start der Software automatisch getriggert (via POL). Leider ist mein Testkandidat, wie bereits erwähnt, eine proprietäre Software, so dass ich sie nicht jedem zum Testen geben kann.

Sobald ich mein Feedback von den Testern aus meinem Umfeld habe und damit ggf. Verbesserungen einfließen, werde ich ein öffentlich verfügbares Paket machen. Dieses muss unter einer entsprechend freien Lizenz sein, nicht nativ unter Linux zur Verfügung stehen und sich am besten auch bereits gut mit wine/playonlinux vertragen (Silber aufwärts).

Derzeit kommt mir dabei nur Notepad++ mit der GPL in den Sinn.

Bitte macht mir Vorschläge für einen öffentlichen Testkandidaten.

Edit: Revision 4 des Codes kann hier eingesehen werden. In src befindet sich der Aufbau der debian Pakete. Für meine Testanwendung habe ich jedoch drive_c aus opt herausgelassen:

http://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/

Hallo allerseits:

habe nun ein Notepad++-Paket gebaut. Näheres zur Installation (zu Testzwecken) habe ich erstmal auf meiner Benutzerseite untergebracht:

http://wiki.ubuntuusers.de/Benutzer/liberavia#Wineports-Projekt

Hallo,

ich war in der Lage mit den gleichen Mechanismen das Spiel Neverwinternights als Debian Paket zu packen und auf einem anderen Computer zu installieren und zu spielen. Das Paket kann ich natürlich nicht veröffenltichen. Nur als Durchsage, dass das Konzept auch mit Spielen tut.

Wie geht es weiter:

1. Ich plane zunächst eine sources-list zur Verfügung zu stellen

2. Als nächstes möchte ich ein PPA erstellen. Hier werde ich mich noch ein wenig einlesen müssen.

Leider kann ich vermutlich in nächster Zukunft nicht so viel Zeit in das Projekt stecken, wie bisher, da ich für ein berufsbegleitendes Studium akzeptiert worden bin und folglich meine eh schon rare Freizeit nun durchs Stuidium ausgefüllt sein wird.

Das bedeutet, dass ich jegliche Hilfe gut gebrauchen kann. Das könnte z. B. sein:

• Softwarevorschläge, die man veröfentlichen kann ohne Anwälte am Hals zu haben 😉

• Mir Hilfestellung geben, um ein entsprechendes PPA erstellen zu können.

• Tested notepad++ und gebt mir Feedback über das Sourceforge Ticket-System

• Lasst andere Menschen, die an dem Projekt interessiert sein können hiervon wissen

Dieses Thema stufe ich als gelöst ein, da aus dem Scriptlösungsansatz ein funktionierendes Konzept geworden ist.

Gruß

André

Als Abhängigkeit wird bei mir playonlinux angegeben. Aber ich kann das Programm doch genau so gut auch über das Setup installieren. Die Idee, Windows-Programme als Debian-Pakete anzubieten klingt zwar ganz interessant, aber erscheint auch irgendwie wenig sinnvoll.

Hi djcj,

Ja in meinem zweiten Ansatz hatte ich mich dazu entschieden, die PlayOnLinux-Infrastruktur direkt zu nutzen, da man mit den Scripten alles perfekt einrichten kann (inkl. für die Anwendung passender Wine-Version)

Die Installation mittels Debian-Paket und das automatisierte Setup via POL bietet dir im Vergleich zur "Setup-Installation" folgende Vorteile:

1. Installation und Deinstallation über das Paketmanagement

2. Die Anwendung ist nach Installation für alle Benutzer systemweit verfügbar

3. Die passende wine-Version und alle für die Anwendung benötigten Einstellungen und Bibliotheken werden beim ersten Start automatisch eingerichtet (zero-conf)

Der zweite Punkt wird besonders bei Spielen interessant, denn wenn ich z. B. Diablo III mit zwei Sysrtem-Benutzerkonten spielen will, sind halt mal 30 GB statt 15 GB belegt 😉

Mein Ziel hinter dem Ganzen ist halt eine weitgehend nahtlose Einbindung einer Windows-Anwendung mittels Wine/PlayOnLinux. Und nahtlos fängt zumindest bei mir schon mit der Installation an.

Wie wäre es mit einem Skript, dass die Paketierung einer Programminstallation unter PlayOnLinux fast vollständig automatisieren würde, sodass man leichter proprietäre Programme wie zB Spiele selbst paketieren und systemweit installieren kann?

djcj schrieb:

Wie wäre es mit einem Skript, dass die Paketierung einer Programminstallation unter PlayOnLinux fast vollständig automatisieren würde, sodass man leichter proprietäre Programme wie zB Spiele selbst paketieren und systemweit installieren kann?

Du wirst lachen, aber genau diesen Gedanken habe ich tatsächlich ☺ Aktuell will ich noch ein paar Erfahrungen mit der Methodik machen und sie weiter verbessern. Glücklicherweise bietet POL ja mit seinem Plugin-System die Möglichkeit solche Gedanken zu verfolgen.

Allerdings ist dieses Feature für den Endanwender wohl eher uninteressant, obwohl es vielleicht sogar als alternative Backup-Lösung taugen könnte. Leider sind die aktuellen Pakete "dreckig" gepackt. Aus Entwicklersicht wäre die Erstellung einer PPA tauglichen Struktur vermutlich noch besser.

Also ich bekomme folgende Fehlermeldung wenn ich alles installiert habe und Notepad++ starten möchte:

1
2
3

~$ /usr/bin/wp_notepadplusplus.py
sh: 1: playonlinux-bash: not found
sh: 1: playonlinux-bash: not found

djcj schrieb:

Also ich bekomme folgende Fehlermeldung wenn ich alles installiert habe und Notepad++ starten möchte:

1 2 3

~$ /usr/bin/wp_notepadplusplus.py sh: 1: playonlinux-bash: not found sh: 1: playonlinux-bash: not found

Welche Distributionsversion verwendest du? Das gleiche Verhalten habe ich hier seltsamerweise auf Ubuntu GNOME 13.10 festgestellt. Playonlinux-bash ist zum Funktionieren des Pakets eine zentral benötigte Anwendung. Auf meinen 12.04 er Installationen hat es geklappt, da hatte ich allerdings auch das Repo von POL angebunden, statt nur das playonlinux-Paket zu installieren. Das Repo gibt es für 13.10 bisher jedoch IMHO nicht.

Leider weiß ich aktuell nicht, wie man playonlinux-bash nachzieht. Sobald playonlinux-bash tut sollte auch Notepad++ laufen (bzw. sich beim ersten Start initial einrichten).

Gruß

André

Für alle, die das gleiche Problem wie djcj haben:

Das Programm befindet sich auch in der ganz normalen PlayOnLinux-Liste und kann von dort gestartet werden. Ich denke mal das Problem ist, dass playonlinux-bash aus dem PlayOnLinux-Repository kommt. Für Saucy, Raring und Quantal gibt es ein solches Repository allerdings nicht.