2. Grundlagen der Entwicklung unter eisfair¶
Am eisfair Projekt arbeiten viele unterschiedliche Entwickler zusammen. Um dennoch ein möglichst reibungsloses Zusammenspiel der einzelnen Pakete und Komponenten zu gewähren, wurden einige Werkzeuge erstellt, aber auch Standards und Regeln abgesprochen und definiert.
Dabei sind die Richtlinien der GPL Lizenz unbedingt einzuhalten. Das bedeutet, eigenentwickelte Programme oder Modifikationen an bekannten Paketen müssen auch im Sourcecode an einer allgemeinzugängigen Stelle einsehbar sein.
2.1. Die Plattform eisfair¶
Sie unterliegt zwar einer ständigen Weiterentwicklung, dennoch werden
einige Grundsätze relevant bleiben. Der Schwerpunkt des Einsatzes
liegt in der Verwendung als Serverplattform. Dabei ist es egal, ob es
sich um einen kleinen energiesparenden Homeserver oder um eine grosse
Datenbankplattform für ein mittelständisches Unternehmen handelt. Die
schnelle Installation von kompletten Lösungen und die einfache
menügestützte Administration sind wichtige Hervorhebungsmerkmale.
Dabei ist immer die Stabilität der Plattform der entscheidende Punkt,
dem sich alle funktionalen Erweiterungen unterordnen. Eventuell nötige
Eingriffe in systemrelevante Komponenten und Konfigurationsdateien
müssen daher immer in Absprache mit dem Entwickler-Team erfolgen. Für
die Umsetzung werden dann möglichst transparente Lösungen oder
allgemeingültige Schnittstellen zum Einsatz kommen. Ein gutes Beispiel
hierfür ist die Datei /etc/services
, welche durch Aufrufen des
Scripts update-services
$package erweitert werden kann.
Bei der Entwicklung von eisfair wird darauf geachtet, daß das System
schlank und schnell bleibt. Übermäßige Verzeichnisbaum-Erweiterungen
(/opt , /usr/local/sbin)
werden vermieden. Auch sollten
Binaries, wenn sie nicht Paketübergreifend verwendet werden, nach
Möglichkeit unterhalb des Verzeichnisses /usr/lib/$package/*
abgelegt werden. Von einzelnen wichtigen Dateien kann man dann immer
noch Symlinks in das Verzeichnis /usr/bin
legen. Das verbessert die
Übersichtlichkeit, vereinfacht die Deinstallation, erhöht die
Sicherheit und bremst das System beim Durchsuchen der ausführbaren
Verzeichnisse nicht aus.
Auf der eisfair Plattform wird man keine man-Page-Verzeichnisse finden. Das ist Absicht. Der eisfair Administrator/Benutzer kommuniziert mit einer speziellen Konfigurationsschicht, deren Parameter und Wirkungsweise in der jeweiligen Paket-Dokumentation verzeichnet sind.
eisfair verwendet zum gegenwärtigen Zeitpunkt die GLibC-2.37 Bibliothek. Deshalb werden aktuelle Pakete anderer Linux-Distributionen nicht auf eisfair funktionieren. Wer Software für eisfair entwickeln möchte, nutzt dazu am besten die Entwicklungsumgebung, siehe [developer].
2.2. Die Entwicklungsumgebung¶
Sie ist in dem Paket Development Environment for eisfair [developer] zusammengefasst. Durch die Installation besitzt man mit dem GCC-Compiler, den Binutils, den Devtools und dem GLibC-Paket eine gute Entwicklungsplattform. Daneben steht bspw. noch Perl zur Verfügung und bei Bedarf kann mit dem kernel-dev Paket der aktuelle Sourcecode für den Kernel hinzugezogen werden.
Beim Kompilieren wird man mitunter feststellen, dass die Umgebung doch
nicht ausreicht. Der eine oder andere Header fehlt einem immer mal
wieder. Jetzt könnte man sich auf die Suche nach dem Sourcecode
begeben und die fehlende Komponente mal eben selber anpassen und
kompilieren. Vorher ist allerdings ein Blick in die „devel“-Kategorie
von Pack-Eis angebracht. Sehr viele Komponenten sind dort,
genau wie das GLibC-Paket, in einer Developer-Version vorhanden. Diese
sollte man aus Kompatibilitätsgründen unbedingt verwenden. Warum das
so empfohlen wird, wird schnell klar: Ein Blick in die optionalen
Parameter bei der Erstellung so mancher Komponenten zeigt eine wahre
Flut von Möglichkeiten der Erstellung auf. Diese können wichtig sein
oder aber zu einem nicht funktionsfähigen System führen.
Deshalb gibt es von jedem Library Paket eine Developer Version. Sie
besteht aus dem Paketnamen, welcher mit dem Library-Paket identisch
ist, erweitert durch den Zusatz -dev
. Also z.B.:
Library Pakete:
libdb
libssl
Developer Pakete:
libdb-dev
libssl-dev
Developer Static Pakete:
libdb-dev-static
libssl-dev-static
Wie man sieht, sollten Library Pakete auch durchaus Versionsinformationen im Namen enthalten. Die meisten Programme benötigen von einer Bibliothek eine ganz bestimmte Version und haben mit neueren oder älteren Fassungen Probleme.
Hinweis
Library Developer Pakete enthalten:
header files
object files
package file with
<require-package>libdb-5_3 2.8.0</require-package>
-tag
Library Developer Static Pakete enthalten:
static libraries
package file with
<require-package>libdb-dev 2.8.0</require-package>
-tag
Vor der Kompilierung von Paketen ist besonders auf die Verzeichnis-
Parametrierung zu achten. Diese ist oft mit Werten vorbelegt, die auch
bei einer unachtsamen Paketerstellung niemandem schaden. Das heißt,
alles wird unter dem Verzeichnis /usr/local
abgelegt. So landen dann
aber auch Konfigurationsparameter und Bibliotheken an Stellen, wo sie
eisfair konform nicht verwendet werden können. Vielfach wird man also
um das übergeben folgender Konfigurationsparameter nicht herumkommen.
Beispiel:
./configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var/lib \
--libdir=/usr/lib \
--libexecdir=/usr/lib/$package
Der Make Befehl ermöglicht oft die Angabe eines Parameters, welcher die eisfair Paketerstellung erleichtert.
make DESTDIR=/tmp/$package install
Alle Dateien werden so in die richtigen Unterverzeichnisse
einsortiert, allerdings nicht in das laufende Betriebsystem sondern
unter das angegebene /tmp/$package
Verzeichnis. Mit dem Strip Befehl
können dann abschließend alle eingebetteten Kommentare und
Anmerkungen aus den fertigen Dateien entfernt werden.
Beispiel:
strip -R .note -R .comment /tmp/$package/usr/bin/*
strip -R .note -R .comment /tmp/$package/usr/lib/*
strip -R .note -R .comment /tmp/$package/usr/lib/$package/*