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/*