<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">
\chapter{Grundlagen der Entwicklung unter \eisfair}

Am \eisfair\ Projekt arbeiten viele unterschiedliche Entwickler zusammen. Um
dennoch ein m"oglichst reibungsloses Zusammenspiel der einzelnen Pakete und
Komponenten zu gew"ahren, 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"ussen auch
im Sourcecode an einer allgemeinzug"angigen Stelle einsehbar sein.


\section{Die Plattform \eisfair}

Sie unterliegt zwar einer st"andigen Weiterentwicklung, dennoch werden einige
Grunds"atze 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"ur ein mittelst"andisches
Unternehmen handelt. Die schnelle Installation von kompletten L"osungen und die
einfache men"ugest"utzte Administration sind wichtige Hervorhebungsmerkmale.
Dabei ist immer die Stabilit"at der Plattform der entscheidende Punkt, dem
sich alle funktionalen Erweiterungen unterordnen. Eventuell n"otige Eingriffe
in systemrelevante Komponenten und Konfigurationsdateien m"ussen daher immer
in Absprache mit dem Entwickler-Team erfolgen. F"ur die Umsetzung werden dann
m"oglichst transparente L"osungen oder allgemeing"ultige Schnittstellen zum
Einsatz kommen. Ein gutes Beispiel hierf"ur ist die Datei \texttt{/etc/services},
welche durch Aufrufen des Scripts \texttt{update-services \package} erweitert
werden kann.

Bei der Entwicklung von \eisfair\ wird darauf geachtet, dass das System schlank
und schnell bleibt. "Uberm"assige Verzeichnisbaum-Erweiterungen (\texttt{/opt}, \texttt{/srv},
\texttt{/usr/local/sbin}) werden vermieden. Auch sollten Binaries, wenn sie nicht
paket"ubergreifend verwendet werden, nach M"oglichkeit unterhalb des Verzeichnisses
\texttt{/usr/local/\package/*} abgelegt werden. Von einzelnen wichtigen Dateien kann man
dann immer noch Symlinks in das Verzeichnis \texttt{/usr/bin} legen. Das verbessert die
"Ubersichtlichkeit, vereinfacht die Deinstallation, erh"oht die Sicherheit und bremst
das System beim Durchsuchen der ausf"uhrbaren 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"artigen Zeitpunkt die \input{glibc-version} Bibliothek.
Deshalb werden aktuelle Pakete anderer Linux-Distributionen nicht auf \eisfair\
funktionieren. Wer Software f"ur \eisfair\ entwickeln m"ochte, nutzt dazu
am besten die Entwicklungsumgebung, siehe [developer].


\section{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"ugung und bei Bedarf kann mit dem
kernel-dev Paket der aktuelle Sourcecode f"ur 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"onnte 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 [pack-eis] angebracht. Sehr viele
Komponenten sind dort, genau wie das glibc-Paket, in einer Developer-Version
vorhanden. Diese sollte man aus Kompatibilit"atsgr"unden 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"oglichkeiten der Erstellung auf. Diese k"onnen wichtig sein oder aber
zu einem nicht funktionsf"ahigen System f"uhren.

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 "`\texttt{ -dev}"'. Also z.B.:

Library Pakete:
\begin{verbatim}
    libdb
    libssl
\end{verbatim}

Developer Pakete:
\begin{verbatim}
    libdb-dev
    libssl-dev
\end{verbatim}

Wie man sieht, sollten Library Pakete auch durchaus Versionsinformationen im
Namen enthalten. Die meisten Programme ben"otigen von einer Bibliothek eine
ganz bestimmte Version und haben mit neueren oder "alteren Fassungen Probleme.

\hinweis{
Library Developer Pakete enthalten:
\begin{itemize}
    \item header files
    \item object files
    \item static libraries
    \item install script
    \item deinstall script
    \item package file with \tag{require-lib}-tag
\end{itemize}
}

Vor der Kompilierung von Paketen ist besonders auf die Verzeichnis-Parametrierung
zu achten. Diese ist oft mit Werten vorbelegt, die auch bei einer unachtsamen
Paket\-erstellung niemandem schaden. Das heisst, alles wird unter dem Verzeichnis
\texttt{/usr/local} abgelegt. So landen dann aber auch Konfigurationsparameter und
Bibliotheken an Stellen, wo sie \eisfair\-konform nicht verwendet werden k"onnen.
Vielfach wird man also um das "ubergeben folgender Konfigurationsparameter nicht
herumkommen.

\begin{example}
Beispiel:
\begin{verbatim}
 ./configure --prefix=/usr                \
             --sysconfdir=/etc            \
             --localstatedir=/var/lib     \
             --libdir=/usr/lib            \
             --libexecdir=/usr/lib/$package

\end{verbatim}
\end{example}


Der Make Befehl erm"oglicht oft die Angabe eines Parameters, welcher die \eisfair\-
Paketerstellung erleichtert.

\begin{example}
\begin{verbatim}
    make DESTDIR=/tmp/$package install
\end{verbatim}
\end{example}

Alle Dateien werden so in die richtigen Unterverzeichnisse einsortiert, allerdings
nicht in das laufende Betriebsystem sondern unter das angegebene \texttt{/tmp/\package}
Verzeichnis.
Mit dem Strip Befehl k"onnen dann abschliessend alle eingebetteten Kommentare und
Anmerkungen aus den fertigen Dateien entfernt werden.

\begin{example}
Beispiel:
\begin{verbatim}
 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/*
\end{verbatim}
\end{example}
</pre></body></html>