Wie erstelle ich Slax-Module richtig?

Slax-Module können in beliebiger Weise erstellt werden, solange du der einzige bist, der sie benutzt. Aber wenn du deine Module mit anderen Anwendern gemeinsam benutzen willst, musst du verschiedene Regeln beachten, die in diesem Dokument beschrieben sind. Die Regeln sind in erster Linie angelegt, dem Endbenutzer zugute zu kommen; also wenn du sie missachtest, wird dein Modul niemals im offiziellen Slax-Repository angenommen werden.

Technischer Überblick

Das Slax Modul ist ein komprimiertes squashfs Dateisystem mit .lzm Erweiterung. Das Modul wurde durch das mksquashfs-Tool erstellt kann durch unsquashfs extrahiert (entpackt) werden. Jedes dieser Tools muss gepatched (modifiziert) werden, um den LZMA Kompressions-Algorithmus zu untersützen. Diese Hilfsprogramme sind bereits in Slax enthalten.

Jedes Slax-Moduls enthält alle Dateien und Ordner mit dem vollem Pfad. Zum Beispiel würde ein Modul mit bash (die binary und einige Handbuchseiten) folgendermaßen aussehen:

/bin/
/bin/bash
/usr/
/usr/man/
/usr/man/man1/
/usr/man/man1/bash.1

Die Regeln

1) Alle Verzeichnise in Ihrem Modul müssen für einen normalen Benutzer nutzbar sein. Setze alle Verzeichnisberechtigungen auf 755 (drwxr-xr-x), unbeachtet dessen, ob es einen sinnvollen Grund gibt, um andere Berechtigungen für ein bestimmtes Verzeichnis zu verwenden.

find ./ -type d | xargs chmod -v 755;

2) Halte deine Module möglichst klein. Dekomprimiere alle deine Archive, die sicherlich unkomprimiert bleiben können (zum Beispiel Handbücher, weil LZMA diese weitaus besser komprimieren kann), lösche alle Dateien welche nicht für den Start der Software benötigt werden (zum Beispiel nicht verwendete Dokumentationen, unbenutzte Sound-Dateien, png/jpg Bilder, nicht verwendete Übersetzungen aus dem /usr/share/locale Ordner) und lösche alle unbenutzen Symbole der Binaries.

find ./usr/man/ -type l -name "*.gz" | xargs -r gunzip -f
find ./usr/man/ ! -type l -name "*.gz" | xargs -r gunzip
find . | xargs file | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded

3) Wenn du die Module aus dem Quellcode kompilierst, stelle bitte das Build-Script zur Verfügung, welches dazu verwendet wird, das Modul zu erstellen. Das Build-Script muss die ganze Modul-Herstellung verwalten können. Jede manuelle Arbeit (Kopieren / Löschen von Dateien, usw) neben dem Build-Script ist nicht erlaubt. Das Script dient als Dokumentation, wie man dein Modul erstellt; mehr noch macht es es einfacher dein Modul zu übernehmen, falls du aufgehört haben solltest, es zu aktualisieren. Kopiere das Build-Script in dein Modul nach:

/usr/src/slaxbuilds/your_module_name.slaxbuild

4) Wenn du deine Software Kompilierst, stelle sicher, dass du die richtigen cflags und Parameter benutzt. Folgendes ist empfohlen, um i486 Anweisungen zu benutzen (welches die beste rückwirkende Kompatibilität liefert), aber dennoch die Leistung des Codes, als wäre die Zielarchitektur i686, zu erreichen. In Slax kannst du einfach 'configure-for-slax' als Verknüpfung benutzen. Es tut das Gleiche:

CFLAGS="-O3 -march=i486 -mtune=i686" ./configure --prefix=/usr --build=i486-Slackware-linux

5) Füge niemals irgendwelche vorhandenen Dateien von Slax in dein Modul, auch wenn du diese modifiziert hast. In anderen Worten, dein Modul sollte niemals eine existierende Datei in Slax 'überschreiben', ungeachtet der Tatsache, dass du einen Guten grund dafür hast, dies zu tun. Dies könnte dein Modul inkompatibel mit neueren Slax-Versionen machen und außerdem könnte es Probleme mit Modulen von anderen Benutzern verursachen. Wenn du unbedingt eine Datei in Slax überschreiben musst (zum Beispiel um ein neuen Pfad zu /etc/ld.so.conf hinzuzufügen), schreibe stattdessen ein Startscript, welches die tatsächliche Datei bearbeitet (updated), anstatt diese von deinem Modul überschreiben zu lassen.

Ein Beispielstartscript, um eine Zeilen aus ld.so.conf zu löschen und eine neue am Ende hinzuzufügen:

#!/bin/bash
sed -i -r '\;/usr/local/lib;d' /etc/ld.so.conf
echo '/opt/kde/lib' >> /etc/ld.so.conf

/etc/init.d
/etc/rc.d/rc.S
/etc/rc.d/rc.M
/etc/rc.d/rc.K
/etc/rc.d/rc.local
/lib/modules/2.6.x/modules.dep
/lib/modules/2.6.x/modules.alias
/etc/ld.so.conf
/etc/ld.so.cache
/etc/passwd
/etc/group
/etc/shadow

6) Wenn du während der Modul-Aktivierung oder beim Start- bzw. Herunterfahren des Systems etwas ausführen musst, benutze die sysvinit-style Verzeichnisse. Die beste Übung ist es ein Universales Script in /etc/rc.d/init.d zu erstellen, welches die 'start' und 'stop' argumente versteht. Alle Scripts in diesem Verzeichnis starten mit dem großem S (um zu Starten) und dem großem K (um zu beenden) in den sysvinit Verzeichnissen abhängig von deinem angestrebten Runlevel, zum Beispiel /etc/rc.d/rc3.d/. Jedes mal, wenn ein Runlevel geändert wird, führt Slax alle Scripts, die mit einem K Starten von dem vorhergegangenen Runlevel-Verzeichnis (um zu beenden) und alle Scipts, die mit einem S beginnen vom dem jetzigen Runlevel-Verzeichnis aus.

Im Folgenden Beispiel führt Slax ' durch; apache.sh start' im runlevel 3 (das während des Einschaltens der Anlage bedeutet) und es führt ' durch; apache.sh stop' in runlevel 0 oder 6 (dieses Mittel, wenn Slax zur Abschaltung oder zum Neustart geht).

# Muster eines allgemeinen Scripts : /etc/rc.d/init.d/apache.sh

#!/bin/bash
if [ "$1" = "start" ]; then
   echo "start apache @ startup"
   ... start apache here ...
fi
if [ "$1" = "stop" ]; then
   echo "stop all apache @ shutdown"
   ... stop apache processes here ...
fi

# Wenn dein allgemeines Script erstellt ist, füge die folgenden symbolischen Verknüpfungen hinzu:

ln -s ../init.d/apache.sh /etc/rc.d/rc3.d/S-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc0.d/K-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc6.d/K-apache

7) Wenn Ihre Software mit GUI gestartet werden kann (z. B. in KDE, XFCE, etc.), müssen Sie ein Icon einbinden und eine Datei mit Menüeintrag Ihrem Modul hinzufügen, so daß der Nutzer das Programm leicht starten kann durch Suche in seinem Menü. Um einen Menüeintrag anzulegen, erzeugen Sie einfach zwei Dateien:

/usr/share/applications/your-application.desktop
/usr/share/pixmaps/your-applications-icon.png

[Desktop Entry]
Encoding=UTF-8
Exec=firefox %u
Icon=/usr/share/pixmaps/firefox.png
Type=Application
Categories=Application;Network;
Name=Firefox
Name[cs]=Firefox
GenericName=Web Browser
GenericName[cs]=Webovy prohlizec
MimeType=text/html
X-KDE-StartupNotify=true

8) Wenn das Programm in Ihrem Modul gestartet wird, sollte es direkt laufen, ohne überflüssige Dialoge, Hinweise oder Lizenzvereinbarungen. Denken Sie daran, daß der Nutzer, wenn er Ihr Modul auf einer nur lesbaren CD einbindet, keine Möglichkeit hat, Einstellungen zu speichern (Tips, Lizenzvereinbarungen etc. abzustellen), daher sollte das Modul ihn nicht bei jedem Start damit belästigen.

9) Abhängigkeiten Ihres Moduls müssen so spärlich sein, wie möglich. Das Mittel, weniger andere Module werden durch Ihr Modul, das bessere angefordert, aber erinnern auch, sich die Größe Ihres Moduls so klein zu halten, wie möglich. Z.B. wenn Ihr Modul ohne Pythonschlange sicher laufen kann, dann stellen Sie sicher, alle Pythonschlangeindexe aus Ihrem Modul, anstelle von der includin Pythonschlange in ihr zu löschen.

Wenn Ihr Modul einige Bibliotheken erfordert, die nur für Ihr Modul praktisch nützlich sind, dann schließen Sie die Bibliotheken direkt in Ihrem Modul mit ein und laden Sie sie nicht separat. Als Beispiel erfordert XFCE viele xfcelib* Bibliotheken, während die durch noch etwas praktisch nicht benötigt sind. So schließen Sie sie im XFCE Modul mit ein.

Andererseits, wenn Ihr Modul weitere Bibliotheken oder Programme benötigt, welche für weitere Module auch nützlich sein könnten, binden Sie diese niemals in Ihr Modul ein, sondern laden Sie diese separat hoch. Beispielsweise Python Bibliotheken sollten stets separat hochgeladen werden und niemals in irgendein Modul eingebunden werden.

Hochladen deiner Module:

Wenn Ihr Modul den Richtlinien folgt, können Sie es mit anderen teilen. Der amtliche Modulbehälter sollte so nützlich sein, wie möglich für die Endbenutzer; aus diesem Grund ist es sehr wichtig, dass jedes Modul eine nette Ikone, ein screenshot hat, das wie darstellt, die Software aussieht wie, wenn Sie sie in frischem Slax (unter Verwendung der Art- und Fensterdekoration der Rückstellung KDE) laufen lassen, und it' s notwendig, eine sinnvolle Beschreibung zur Verfügung zu stellen, die Leuten hilft, mehr über das Modul zu verstehen.

Einige Bibliotheken oder Programme zeigen keine Benutzerschnittstelle, dadurch, dass Fälle das screenshot nicht erforderlich ist. Aber ein nettes, truecolor Ikone muss zur Verfügung gestellt werden. Module ohne Ikone werden selten angenommen. Wenn Sie dass it' denken; s, das nicht möglich ist, eine Ikone für Ihr Modul zu finden, denken dann wieder. Es doesn' t-Notwendigkeit, für Ihr Modul einzigartig zu sein, aber der Benutzer sollten in der Lage sein, zwischen einem Maskeneditor und einem eMail-Klienten gerade durch einen schnellen Blick an den Ikonen zu unterscheiden.

Der Titel sollte keine nicht benötigten Schläge und Unterstreichen enthalten, einfach dort gesetzt dem Software-Namen, gefolgt von der Versionsnummer. Das folgende ist korrekt: vim 7.1. Das Folgende ist nicht korrekt: vim_7.1-112-i486-15

Die Beschreibung muss lang genug sein, um den Kategorienüberblick nett zu gestalten, aber er sollte nur nützliche Informationen für den Benutzer enthalten. Dies heißt, das Modul für jemanden zu beschreiben, der absolut keine Idee vom Inhalt und Nutzen hat. Keine komischen Texte, keine Verweise, keine Grammatik- oder Rechtschreibfehler, keine Ausrufungszeichen und keine Änderungen. Empfohlene Länge sind 40 Wörter oder mehr.