Vom Programm zum Produkt

Diese Notizen sind noch nicht komplett und auch noch nicht mit
Auszeichnungen versehen.


Andere Dokumente zum Thema: GNU coding standards, insbesondere
Abschnitt "Managing Releases".

Man kann noch soviel hoeren und lesen zu dem Thema, am besten man
installiert einmal ein paar Pakete, um ein Gefuehl dafuer zu bekommen,
was richtig ist und was falsch.


Account:

Für die Übung erhalten Sie einen Account auf folgenden Maschinen:

Maschine Betriebssystem		Eigenschaften
mips 	 Digital Unix		64-bit, little-endian, modernes Unix
a5,a4,a7 Linux-Alpha		64-bit, little-endian, modernes Unix
pcs	 Linux-Intel		32-bit, little-endian, modernes Unix
d0,d1	 Ultrix			32-bit, little-endian, altes Unix
jupiter	 SunOS			32-bit, big-endian, altes Unix

Bei diesem Account hängt die X-Session am Emacs, wenn sie also aus dem
Emacs aussteigen (Ctrl-x Ctrl-c Space), loggen Sie sich aus.  Wenn Sie
Ihr Passwort aendern, aendert es sich nur auf der Maschine, wo sie es
geaendert haben.

Beachten sie, dass alle Maschinen ausser die mips und die Linux-Alphas
nur mit Maschinen der Abteilung reden; wenn sie sich also von aussen
einloggen, dann auf die mips oder die Linux-Alphas und von dort dann
auf die anderen Maschinen.


Ein typischer Installationsvorgang

wget ftp://host/directory/package.tar.gz
tar xvfz package.tar.gz
cd package
emacs README
./configure
make
make check
make install


Das Paketformat

Standardformat in Unix: tar

Andere Formate:

zip: DOS, Unix (maessig verbreitet); etwas weniger komprimiert als
.tar.gz. pkunzip (DOS-Entpackwerkzeug, Shareware) ignoriert per
Default, in welchen Directory die Dateien liegen.

Systemabhaengige Formate, z.B. rpm (einige Linux-Distributionen)
dienen vor allem für binary distributions.

shar: (shell archive); schlecht (wie alle selbstextrahierenden
Paketformate): man kann nicht vorher nachschauen, was drinnen ist, und
auch nicht einzelne Files extrahieren. Bei shar kommt noch dazu, dass
es nicht merkt, wenn es kaputt ist (was drinnen sein sollte,
sollte in der Datei MANIFEST stehen).

Kompression:

compress (.Z): unter Unix ueberall vorhanden, darf aber nicht mehr
weiterentwickelt werden.

gzip (.gz): ueberall vorhanden, wo nicht nur vorgekaute Software
installiert wird. Etwas bessere Kompression als compress. Empfohlen.

bzip (.bz, .bz2): Etwas bessere Kompression als gzip, aber kaum
verbreitet.

Abkuerzungen (fuer das Abspeichern auf hirntoten Dateisystemen):

.tgz=.tar.gz
.taz=.tar.Z

Inhalt:

Immer nur ein Directory einpacken, nicht einen Haufen Dateien, sonst
hat der Benutzer einen Haufen Files in dem Directory darüber, wo er
sie nicht wollte! Vorsicht beim Auspacken: besonders .zip-Files, aber
auch manche Anfänger-.tar.gz-Dateien sind falsch verpackt.


README

Niemals ohne README (comp.sources-Richtline)! Beantwortet
folgende Fragen (in Englisch):

Was ist das Paket, wozu ist es gut? Wo bekomme ich neue Versionen oder
zusätzliche Informationen? Wie compiliere und installiere ich es
(eventuell ausgelagert in INSTALL)? Wo melde ich Probleme?  Was sind
die Lizenzbedingungen (eventuell ausgelagert in COPYING oder LICENSE)?
Was sind die Aenderungen seit Release xxx (meistens in Datei NEWS oder
ChangeLog ausgelagert)

Bei Auslagerung sollte man im README auf jeden Fall einen Hinweis
geben, was wo zu finden ist.


Konfiguration, Portabilität:

Wenn das Programm nicht nur auf einer Unix-Variante laufen soll,
sollte man es auf verschiedenen Maschinen testen; die Systeme sollten
sich u.a. in folgenden Aspekten unterscheiden:

Byte order: Big-Endian (z.B. Irix) vs. little-endian (z.B. Ultrix)
Word size: Pseudo-64-Bit (z.B. Linux-Alpha) vs. 32-bit (z.B. Linux-Intel).
Alter: antikes (z.B. SunOS, Ultrix) vs. modern (z.B. Linux, Digital Unix)
Dialekt: BSD (z.B. SunOS) vs. System V (z.B. Solaris) vs. anderes (z.B. Linux)
Tools: Compiler, Make etc. verschieder Systeme und GNU-Varianten

Wenn man einen bestimmten Aspekt auf verschiedenen Maschinen
unterschiedlich behandeln muss:

- Mit configure abtesten, wie er behandelt werden muss (autoconf ist
super): Funktioniert gut, sehr flexibel.

- Mit xmkmf bekannte Systemeigenschaften einbinden: funktioniert gut,
aber nur fuer bestimmte Aspekte.

- #ifdef auf ein vom Compiler oder einem .h-File definiertes Symbol
(z.B. __linux__): funktioniert nicht immer richtig (z.B. andere
Systemversion, oder nicht getestetes System), und kann nur an manchen
Stellen verwendet werden (z.B. in C-Files).

Deklarationsprobleme bei C:

Oft werden Funktionen auf einem System deklariert, auf einem anderen
nicht; wenn das Programm sie nicht selbst deklariert, bekommt man auf
dem System ohne Deklarationen warnings. Manche Leute versuchen, das
Problem dadurch zu umgehen, dass sie die Funktion jedenfalls selbst
deklarieren. Das ist in vielen Faellen keine gute Idee, denn wenn ein
System die Funktion mit einem leicht abweichenden Typ (z.B. mit einem
const mehr oder weniger) deklariert, gibt es einen Error auf diesem
System. Deklarieren sollte man nur Return-Typen, die nicht automatisch
auf int konvertieren (insb. float und double).


Makefile:

(siehe auch Gnu Coding Standards, Makefile conventions)

Achtung: Im Makefile wird die einfache Bourne Shell verwendet
(/bin/sh), und die ist auf manchen Systemen ziehmlich gestoert
(z.B. if...then...fi liefert in einem Fall immer einen Fehler).

Ausserdem ist . bei vielen Installateuren (oft Sysadmins) nicht in
PATH.

Standard-targets:

all und default: baut das Programm bis zum lauffaehigen Zustand, sodass
man es nur noch installieren muss.

clean: loescht alles, was von "make all" gebaut wird, stellt also den
Zustand nach "configure" wieder her.

distclean: Stellt den Zustand nach dem Auspacken wieder her.

check: fuehrt Selbstests aus. Am besten, man kriegt nur ein "ok" oder
"kaputt", und nicht einen Haufen Meldungen, die einem nichts sagen.

install: kopiert die fuer die Benutzung benoetigten Teile des
Programms in die entsprechenden Directories (die es ggf. erst
kreiert). Danach kann man das Directory "package" loeschen.

installcheck: Wie check, nur verwendet es die installierte Version des
Programms.

uninstall: Entfernt das Programm wieder.

dist: Packt das Programm ein; Die Benutzer brauchen das zwar
normalerweise nicht, aber die Paketmaintainer lernen es schnell zu
schaetzen, dass sie nicht jedesmal, wenn sie wieder auf ein Problem
draufkommen und etwas aendern, alles von Hand einpacken muessen.

info, dvi: Im Falle einer Dokumentation mittels Texinfo erzeugt man
damit die info-Variante, bzw. die druckbare Variante als
(TeX)-dvi-File.


make install

Normalerweise Installation in der /usr/local Hierarchie, sollte aber
konfigurierbar sein.

In der Hierarchie in folgenden directories

bin: vom Benutzer verwendete ausfuehrbare Dateien.

sbin: vom Systemadministrator verwendete ausfuehrbare Dateien.

man/man1 etc.: Doku im man-Format

info: Doku im info-Format

share: andere maschinenunabhaengige Dateien (gibt's u.U. nur einmal
für alle Maschinen), normalerweise in einem eigenen Directory für das
Paket. Noch nicht besonders weit verbreitet.

lib: andere (maschinenabhaengige) Dateien, normalerweise in einem
eigenen Directory für das Paket.

include: .h-Files


Versionen:

Es ist eine gute Idee, verschiedene Versionen in verschiedene Files
bzw. Directories zu legen (z.B. foo/0.1.2, foo/0.2.1 usw.), damit die
Benutzer mehrere Versionen gleichzeitig installiert haben
koennen. Insbesondere beim share-Directory ist das wichtig (da auf den
verschiedenen Maschinen eventuell verschiedene Versionen installiert
werden). Fuer die ausführbare Datei: Alle Versionen mit Versionsnummer
(foo-0.1.2), die zuletzt installierte auch ohne (foo), als link.


Dokumentation:

Formate:

man: eher für kuerzere Doku

texinfo: erlaubt on-line-Hypertext (info oder HTML) und hardcopy,
besonders fuer laengere Doku geeignet. Bei make install sollte man auf
jeden Fall die info-Variante installieren, HTML-Doku hat sich noch
nicht richtig etabliert.

andere Formate: nicht etabliert, daher nicht zu empfehlen.




[Making
Packager-Friendly Software]

Anton Ertl