Code-Konventionen#

Für eine möglichst einheitliche Paketstruktur haben wir uns auf einige grundlegende Absprachen festgelegt.

Benennung von Sektionen#

Sektionstyp und Sektionsnamen durch Unterstrich _ trennen, z. B. Files_Copy. Der Name sollte das beschreiben, was die Sektion tut, z. B.

  • Files_Copy: Kopieren von Installationsdateien

  • Files_Delete: Löschen von Programmdateien

  • Files_Cleanup: Löschen von Programmresten nach der Deinstallation

Schreibweisen#

  • Leerzeilen sind nur zwischen Sektionen zu verwenden und nicht innerhalb einer Sektion.

  • Alle Pfadangaben werden in doppelten Anführungszeichen („Pfad“) angegeben.

  • Variablen sollten am Anfang, in der Sektion [Initial], in CamelCase deklariert werden. Beispiele: $ExitCode$, $Reboot$

  • Unter [Actions] sollte kein eingerückter Code wie z. B. if-Blöcke stehen, sondern nur Aufrufe an Sub-Blöcke. Der entsprechende Code kann einfach in einen entsprechenden Sub-Block ausgelagert werden (z. B. Sub_Check).

Dateien und Ordner#

  • Alle winst-Scripte sollten die Erweiterung .ins haben; Include-Dateien die Erweiterung .inc.ins.

  • Alle unmodifizierten Dateien vom Upstream-Hersteller sollten im Unterordner data liegen.

  • Alle Dateien vom Paketersteller (Sie) sollten im Paketordner, aber nicht in data-Verzeichnis liegen.

  • Sollen vorgegebene Dateien während der Installation modifiziert werden, kopiert man sie erst und modifiziert sie, wenn möglich, mit Hilfe von winst. (Patches-, PatchTextFile-, XMLPatch-Sektionen).

  • Datenablage (Verzeichnisse, wo alle Benutzer Zugriff drauf haben müssen), liegen in /srv/appdata/<paketname>. Die Schreibrechte sollten so restriktiv wie möglich sein (Eigentümer root:root; 755 für Ordner, 644 für Dateien). Ordner, die für Benutzer schreibbar sein müssen, werden auf root:root 777 gesetzt.

  • Jedes Paket muss ein Changelog /srv/deploy/install/<paketname>/changelog haben.

  • Das Paket muss ein sinnvolles Logo (PNG, 160x160px) haben.

Dokumentation innerhalb eines Paketes#

  • Alle Workarounds, die vom Standard-Ablauf abweichen, sollten dokumentiert werden, z. B. Sleep-Aufrufe, spezielle MSI-Parameter, oder die Parameter der diversen Setups.

  • Wenn möglich, Internetquellen angeben.

  • Dokumentation, die über wenige Zeilen hinaus gehen, sind in einer zusätzlich README.md Datei zu dokumentieren, damit die Lesbarkeit des Installationsskriptes nicht leidet.

  • Wenn besondere Schritte erforderlich sind, um das appdata-Verzeichnis aus der Software zu extrahieren, oder die Daten darin für den Betrieb mit IServ angepasst werden müssen, müssen diese Schritte in README.md dokumentiert werden.

msiexec Aufrufe#

Alle msiexec-Aufrufe sollten die folgenden Parameter verwenden:

  • Installation: msiexec /passive /i "%ScriptPath%datapaket.msi" [OPTION=WERT]...

  • Deinstallation: msiexec /passive /x "%ScriptPath%datapaket.msi" [OPTION=WERT]...

Alle Abweichungen sollten dokumentiert werden. In bestimmten Fällen (z. B. bei der Deinstallation von SMART Notebook) funktioniert /passive nicht (gibt eine Frage aus); in dem Fall funktioniert /qn besser, was dann allerdings als Ausnahme dokumentiert werden muss.