Software > Programmieren, Kompilieren
GCC 2.95.3 für Solaris 2.5.1
escimo:
...Bevor es zum Paketbau kommt noch eine Kleinigkeit. Die folgenden Verzeichnisse existieren nach erfolgter Kompilierung und Installation in das Verzeichnis /opt/gnu:
# ls /opt/gnu
bin include info lib man sun-sparc-solaris2.5.1
Da habe ich noch ein klein wenig frisiert...
# rm -Rf include/ info/ sun-sun-sparc-solaris2.5.1/
...so dass nur noch....
# ls /opt/gnu
bin lib man
...übrig bleiben. Danach habe ich die Test(s) gefahren.
Ich hoffe, dass hinterlässt kein instabiles Compiler-System. Bis jetzt hat jeder Übersetzungslauf ohne erkennbare Fehler bzw. ein Fehlverhalten funktioniert. :-\
Innerhalb der nächsten Woche dann endlich der Beitrag, wie man nun den C-Compiler in ein Paket schnürrt.
Gruß
escimo
escimo:
Für ungeduldige Leser...
Interessanter Weise gab es zum Thema Paketbau dazu von Christopher Atlan (Lordy) schon eine FAQ unter [Gewusst wie...] -> Anleitung zum Bau von Solaris Installationspaketen
Die Variante bezogen auf das "GNU C-Compiler 2.95.3"-Kompilat ist in Arbeit und folgt demnächst.
escimo
escimo:
Ich sitze gerade am Paketbau und der "Kurz"-Dokumentation. Mir ist beim Wuseln aufgefallen, dass ich das include-Verzeichnis eventuell doch noch benötige, obwohl es unter /opt/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include auch vorhanden ist.
Diesen Konfigurationsschalter "--with-local-prefix=/opt/gnu" habe ich ja beim zweiten erfolgreichen Compilerlauf nicht angegeben. Das bedeutet aber, dass der Compiler jetzt standardmäßig unter /usr/local/include nach einigen Headern - zusätzlich zu /usr/include - sucht.
Unter $GCCSRC/gcc-2.95.3/gcc/INSTALL steht dazu...
--- Zitat -----with-local-prefix=dirname
Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.
You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.
The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.
The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)
Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.
Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.
GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.
Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).
The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.
Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.
--- Ende Zitat ---
Obwohl das Paket später nach /usr/local installiert werden können soll, benötige ich eventuell doch dieses Verzeichnis und sei es nur ein symbolischer Link.
Die Frage ist, wie ich diese Klippe am sichersten umschiffen kann!? ???
Gruß
escimo
escimo:
Geschafft!
Die Klippe habe ich mal nicht umschifft, sondern "ratze fatze" Klippe sein lassen, damit ich das Paket fertigstellen konnte. Nun ist es soweit und obwohl ich ein mittelgroßes Problem mit dem Kommando pkgmk hatte, habe ich es heute - ehm gestern - während der Zugfahrt von Frankfurt endlich geschafft das Paket zu erstellen. :D
Hier ist das Paket für jeden, der es mal ausprobieren möchte: GNUccomp_2.95.3.Z
I Hinweise zum angebotenen Paket
* Es handelt sich um ein Alpha-Release des Paketes.
* Das Paket enthält Binaries, die einzig für SPARC (V8) kompiliert wurden.
* Das Paket liegt im "*.Z"-Format vor, um vorzubeugen, falls kein GZIP auf der alten Solaris/SPARC-Maschine installiert ist.
* In späteren Paketen fließt die Architektur-Bezeichnung, Betriebssystem-Bezeichnung und -Version in den Paketnamen mit ein.
* Das Paket kann mittels "uncompress GNUccomp_2.95.3.Z" enpackt werden.
* Informationen zum Paket lassen sich u.a. mit dem Kommando "pkgparam -v -d /GNUccomp_2.95.3 GNUccomp DESC ARCH EMAIL" ausgeben.
* Anschließend kann mittels "pkgadd -d /path/to/GNUccomp_2.95.3" der C-Compiler installiert werden.
II Meine Anforderungen an das Paket
Aber wiederholen wir zunächst nochmal ein Paar Fakten und stellen einige Anforderungen an unser neues zu erstellendes Paket:
* Das Kompilat wurde mittels make install unter /opt/gnu installiert und besitzt eine separate Verzeichnisstruktur (bin/, lib/, man/)
* Ziel war die Erzeugung eines SVR4-Paketes, das sich auf beliebigen SunOS 5.x SPARC-Systemen mittels pkgadd installieren beziehungsweise mittels pkgrm wieder entfernen lässt.
* Es wird festgelegt, dass die Installation Standard-mäßig in das Verzeichnis /usr/local erfolgt
* future TODO: pre-/postinstall- und pre-/postremove-Skripte für das Modifizieren von (bestehenden) Dateien im File-System
* future TODO: request-und checkinstall-Skripte für parametriesierbare Installation (Auswahl und Erstellung des Installationsverzeichnisses)
* future TODO: mehrere Compiler (C, C++, Fortran) in einen Paket-Stream zusammenfassen
III Literatur zum Bau von Paketen
* Manual Pages zu Kommandos pkgproto(1), pkgmk(1), pkgtrans(1), pkgchk(1), pkginfo(1), pkgparam(1), pkgadd(1M), pkgrm(1M)
* Manual Pages zu Informationsdateien pkginfo(4), prototype(4), pkgmap(4), copyright(4), depend(4), admin(4), compver(4), space(4)
* Sun "Application Packaging Developer's Guide" (en)
"So, jetzt geht es langsam los..." ;)
1 Einstieg in den Bau von SVR4-Paketen (Solaris)
1.1 Wozu Pakete
Pakete dienen dem Ausliefern von Anwendungs-Software. Sie werden in der Regel von dem Entwicklern geplant und erstellt, nachdem ein Softwareprodukt fertiggestellt wurde. So kann im weiteren Verlauf sichergestellt werden, dass die Software mit standardisierten Mitteln verteilt und installiert werden kann.
1.2 Was ist ein Paket:
Ein Paket ist eine Sammlung von Dateien und Verzeichnissen, die in einem definierten Format vorliegen. Dieses Format stimmt mit den Vorgaben des ABI (Application Binary Interface), das einen Zusatz zur System-V Schnittstellendefinition bildet, überein.
Für gewöhnlich wird ein Software-Produkt in einem bis mehreren Paketen ausgeliefert. Der Paketinhalt wird in zwei Kategorien gegliedert:
* Paketobjekte als die auszuliefernde Software
* Kontrolldateien, bestehend aus Imformationsdateien und Installationsskripten für benutzerspezifische Installtionen
1.3 Inhalt eines Paketes
Zweck eines Paketes ist die Auslieferung von Software einer Kategorie als Paketobjekt. Folgende Arten von Paketobjekten werden unterstützt:
* Dateien (Binär, Text)
* Verzeichnisse
* Named Pipes
* Links
* Devices
Um ein Paket mit zur Verfügung stehenden Kommandos (z.B. pkgmk) erstellen zu können, müssen zusätzlich zu den Paketobjekten (der eigentlichen Software) nächst einige dieser Kontroldateien erstellt werden:
* benötigte Informationsdateien pkginfo und prototype
* optionale Informationsdateien compver, depend, space, copyright
Alle Installationsscripte sind optional und können bei Bedarf erstellt werden. Zu ihnen zählen unter anderem:
* request-Skript
* checkinstall-Skript (ab Solaris 2.5 verfügbar)
* preinstall, postinstall, preremove, postremove als allgemeine Verarbeitungsskripte
* Klassen-Verarbeitungsscripte
1.4 Allgemeine Anforderungen an ein Paket
Überlegungen vor dem Bau eines Paketes für ein Softwareprodukt (future TODO's):
* besteht das auszuliefernde Softwareprodukt aus einem oder mehreren Paketen
* wie segmentiere ich das Softwareprodukt für die Auslieferung bei mehreren Paketen
Welchen Anforderungen sollten Pakete entsprechen:
* Pakete sollten sich relativ zum Pfad installieren lassen (Remote-Installation)
* Pakete werden in funktionale Einheiten zusammengefasst und auf nötige Funktionen begrenzt
* Berücksichtigung von Client-/Server-Architekturen (Pakete für Clients und Server)
* Lizenz-pflichtige Software wird in separaten Paketen ausgeliefert
* Software wird je nach System-Abhängigkeiten in separaten Paketen ausgeliefert (SPARC, x86, x64)
* Duplikate (Kürzel) von Paketobjekten (Dateien) sollten vermieden werden; Aufsplittung der Software in Paket-Elemente (z.B. SWcommon, SWccomp, SWcpluscomp, SWfcomp, SWpcomp)
* unterschiedliche Lokalisierungen/Sprachversionen (en, de, fr, it, ...) des Softwareproduktes sollten in separate Pakete verpackt werden
Soviel zu Teil I. Die Beschreibung zum konkreten [WIE] (Teil II) folgt später ... *gähn* ... heute...
Bis dahin.
Gruß
escimo
escimo:
...ausgeschlafen und immer noch hungrig geht's weiter... Zugegeben, das Paket ist alles andere als perfekt. - Es ist ein Anfang. ;)
2 Erstellung eines SVR4-Paketes
2.1 Schritte zur Erstellung eines Paketes
* Organisation des Paketinhaltes in einer hierarchischen Verzeichnisstruktur
* Vergabe/Anpassung von UID, GID und Datei-Rechten auf alle Paketobjekte (für Zielumgebung)
* Erzeugung der benötigten Informationsdatei pkginfo
* [OPTIONAL] Erzeugen von optionalen Informationsdateien, z.B. Definition von Paketabhängigkeiten (-> depend), Einbindung von Copyright-Texten (-> copyright), Reservierung von zusätzlichen Speicherplatz auf den Zielsysteme (-> space)
* [OPTIONAL] Erzeugen von Installtionsskripten pre-/postinstall sowie pre-/postremove (benutzerspezifische Installation/Deinstalltion)
* Erzeugen der Informationsdatei prototype
* Erzeugen des Paketes mit dem Kommando pkgmk
* Verifizierung/Test der Integrität des erzeugten Paketes mit den Kommandos pkgchk und pkgparam
* Transfer des Paketes im Paketformat auf ein Distributionsmedium mit dem Kommando pkgtrans
2.1 Organisation der Verzeichnisstruktur und Anpassungen der Paketobjekte
Da die Verzeichnisstruktur bereits angepasst wurde (-> siehe hier), fehlt noch die Vergabe entsprechender Privilegien auf die Paketobjekte für die spätere Zielplattform/-installation. In diesem Beispiel wurde das Paket nach /opt/gnu installiert, was für ein Paketbau keine gute Idee war. Somit ist zusätzlich ein su erforderlich.
--- Code: ---sypho% cd /opt/gnu
sypho% su
Password:
# chown -R bin:bin ./*
# chmod -R 755 ./*
# ^D
logout
sypho%
--- Ende Code ---
Folgende Richtlinien sind zu beachten:
* Der Paketinhalt ist stets in einem eigenen Verzeichnis organisiert.
* Das Verzeichnis weist die Struktur des späteres Zielsystems auf (/usr, /bin, usw.)
* Die Zugriffsrechte sollten denen des späteren Zielsystems entsprechen.
2.2 Erstellung der Informationsdatei pkginfo
Die Informationsdatei pkginfo ist eine ASCII-Datei die einige Eigenschaften (Charakteristika) des Paketes beschreibt, die für den weiteren Installationsverlauf benötigt werden. Da es hier keinerlei mitgelieferten Automatismus (Skript o.ä.) gibt, der einen das Tippen teilweise abnimmt, muss man mit seinem bevorzugten Editor die Datei selbst zusammenstellen:
--- Code: ---sypho% cd $HOME
sypho% pwd
/home/schaarst
sypho% mkdir InfoFiles
sypho% cd InfoFiles
sypho% pwd
/home/schaarst
sypho% vi pkginfo
--- Ende Code ---
Jeder Eintrag beziehungsweise jede Zeile besteht aus einem Schlüssel-Werte-Paar im Format "PARAM=Value". Bei mehr als einer Wertangabe muss diese in einfache oder doppelte Anführungszeichen eingeschlossen werden ("Wert1 Wert" oder 'Wert1 Wert 2'). Sollten Sonderzeichen verwendet werden, so muss dieses im Format "\x" erfolgen.
Folgende Standard-Parameter müssen in der Datei pkginfo definiert werden: PKG, NAME, ARCH, VERSION und CATEGORY. Folgende Einträge habe ich hinzugefügt:
--- Code: (bash) ---PKG="GNUccomp"
NAME="GNU C Compiler (created on Solaris 2.5.1)"
ARCH="sparc"
VERSION="2.95.3"
CATEGORY="application"
DESC="GNU C Compiler for program development on the Solaris 2.5.1 Operating Environment and compatible operating systems on SPARC V8 platforms."
VENDOR="Free Software Foundation, Inc."
EMAIL="escimome-please@yahoo.de"
PSTAMP="escimo for sonnenblen.de"
ISTATES="S 2"
RSTATES="S 2"
BASEDIR="/usr/local"
--- Ende Code ---
Erklärung zu den Parametern in der pkginfo-Datei:
* PKG -> Kürzel für Paketnamen (z.B. GNUapp); max. 32 Zeichen
* NAME -> voller Name des Paketes
* ARCH -> Ziel-Architekur des Paketes
* VERSION -> Paketversion (kann alternativ auch für Programmversion verwendet werden)
* CATEGORY -> Zugehörigkeit zu Software-Kategorie ("system", "application")
* DESC -> Beschreibung zum Paketinhalte
* VENDOR -> Hersteller der Paketquellen
* EMAIL -> Kontakt-Adresse einer Ansprechperson für Fragen/Support
* PSTAMP -> kann zum Erzeugen einen "package prducer stamps" genutzt werden
* ISTATES -> bevorzugte init-Statuse, in denen das Paket installiert werden sollte.
* RSTATES -> bevorzugte init-Statuse, in denen das Paket entfernt werden sollte.
* BASEDIR -> Angabe eine absoluten Pfades zu einem Verzeichnisses, in das die Paketobjekte installiert werden.Darüberhinaus gibt es auch noch andere Parameter wie CLASSES, auf die an dieser Stelle nicht näher eingegangen wird.
2.3 Erzeugen der Informationsdatei prototype
Die Informationsdatei prototype ist ebenfalls eine ASCII-Datei. Sie dient dem formatierten/spezifischen Listen aller Objekte eines Paketes und weiterer Informationen, die für das Kommando pkgmk benötigt werden. Dabei beschreibt jede Zeile ein einzelnes Objekt des Paketes nach einem festgelegten Format. Grundsätzlich lässt sich die prototype-Datei auch von Hand erstellen, was aber unter Umständen je nach Paketinhalt und -größe sehr zeitaufwändig werden kann. Das ist nötig, wenn der Paketinhalt vorher nicht organisiert und in einer Hierarchie zusammengefasst wurde. Für unseren Fall bedienen wir uns dem Kommando pkgproto, da wir die notwendigen Datei-Organisierung bereits vorgenommen haben:
--- Code: ---sypho% cd $HOME
sypho% pwd
/home/schaarst
sypho% mkdir InfoFiles
sypho% cd /opt/gnu
sypho% pwd
/opt/gnu
sypho% pkgproto bin lib man > /home/schaarst/InfoFiles/prototype
--- Ende Code ---
Die Anweisung "pkgproto bin lib man > /home/schaarst/InfoFiles/prototype" erstellt eine Datei mit der Bezeichnung "prototype" im Verzeichnis /home/schaarst/InfoFiles. Die 3 Pfad-Parameter im Format "Path1[=Path2]" dienen der Angabe des Pfades, wo sich Paketobjekte befinden. Wird die Option "=Path2" an Path1 angehängt, wird die Pfadangabe von Path1 mit der von Path2 in der prototype-Datei substituiert.
Folgenden Inhalt hat die prototype-Datei nach Ausführung der Anweisung:
--- Code: ---d none bin 0755 bin bin
s none bin/cc=gcc
f none bin/protoize 0755 bin bin
f none bin/unprotoize 0755 bin bin
f none bin/gcov 0755 bin bin
f none bin/cpp 0755 bin bin
f none bin/gcc 0755 bin bin
d none lib 0755 bin bin
d none lib/gcc-lib 0755 bin bin
d none lib/gcc-lib/sparc-sun-solaris2.5.1 0755 bin bin
d none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3 0755 bin bin
d none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/math.h 0644 bin bin
d none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/sys 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/sys/stream.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/curses.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/assert.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/syslimits.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/stdarg.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/stddef.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/varargs.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-alpha.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-h8300.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-i860.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-i960.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-mips.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-m88k.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-mn10200.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-mn10300.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-pa.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-pyr.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-sparc.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-clipper.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-spur.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-m32r.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-sh.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-v850.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/proto.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-arc.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/iso646.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-ppc.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/va-c4x.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/stdbool.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/limits.h 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/README 0644 bin bin
d none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/v7 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/include/fixed 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/cc1 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/collect2 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/crt1.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/crti.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/crtn.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/gcrt1.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/gmon.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/crtbegin.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/crtend.o 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/specs 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/SYSCALLS.c.X 0644 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/cpp0 0755 bin bin
f none lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.3/libgcc.a 0644 bin bin
f none lib/libiberty.a 0644 bin bin
d none man 0755 bin bin
d none man/man1 0755 bin bin
f none man/man1/gcc.1 0444 bin bin
f none man/man1/cccp.1 0444 bin bin
--- Ende Code ---
Nehmen wir uns mal den Eintrag "f none bin/gcc 0755 bin bin" aus der Datei prototype und erklären deren Bedeutung:
* "f" -> bezeichnet den Objekt-Typ (hier f=file, d=directory, s=symbolic link)
* "none" -> bezeichnet die Klasse zu der das Objekt gehört. Ohne Angabe des Parameters "CLASSES" in der Informationsdatei pkginfo wird "none" angenommen und bei Aufruf des Kommandos pkgmk in der pkginfo-Datei ergänzt.
* "bin/gcc" -> gibt den Pfad (entw. relativ oder absolut) an, wohin das Objekt/die Datei durch das Kommando pkgadd installiert wird.
* "0755" -> beschreibt die Objekt-Privilegiun als oktalen Wert (-rxwr-xr-x). Alternativ kann auch das Fragezeichen "?" gesetzt werden, womit die Privilegien denen des bereits vorhandenen Objektes (beim Überschreiben) auf dem Zielsystem entsprechen.
* "bin" -> Benutzername des Eigentümers der Datei
* "bin" -> Gruppenname des Eigentümers der Datei
Bevor wir das Paket mit dem Kommando pkgmk aufrufen können, müssen wir dem in der prototype-Datei noch eintragen, wo die pkginfo-Datei zu finden ist. Dazu kann wieder der bevorzugte Editor benutzt werden, der bei mir nicht unbedingt vi ist ;D aber überall vorhanden ist.
--- Code: ---sypho% cd $HOME/InfoFiles
sypho% pwd
/home/schaarst/InfoFiles
sypho% ls
pkginfo prototype
sypho% vi prototype
--- Ende Code ---
--- Code: (bash) ---i pkginfo
--- Ende Code ---
Durch Einfügen von "i pkginfo" (include) wird dem Kommando pkgmk vermittelt, dass sich die Datei pkginfo im selben Verzeichnis befindet wie die prototype-Datei. Sollte die pkginfo-Datei in einem anderen Verzeichnis liegen, kann im Format "pkginfo=<Pfad>" auch ein alternativer Pfad (relativ oder absolut) angegeben werden. Darüberhinaus können auch weitere solcher Einträge genutzt werden, wie z.B.
* i copyright=/path/to/my/copyright.file
* !include InfoFile/prototype2
* !default 0755 schaarst users
* !search /home/schaarst/moreInstallAndInfoFiles
2.4 Erzeugen des Paketes mit dem Kommando pkgmk
Jetzt kommt der kritische Schritt: Das automatisierte Erzeugen des Paketes mit dem Kommando pkgmk. Folgende Aufgaben erledigt das pkgmk-Kommando für uns:
* Aufbereiten aller in der prototype-Datei definierten Objekte zu einem Verzeichnis-Format.
* Erstellen der Datei pkgmap, um die Datei prototype zu ersetzen.
* Zusammenstellen einen installierbaren Paketes als Eingabedaten für das Kommando pkgadd.
Versuchen wir es mal:
--- Code: ---sypho% cd $HOME/InfoFiles
sypho% pwd
/home/schaarst/InfoFiles
sypho% pkgmk
## pkgmap wird erzeugt aus Package-Prototypdatei.
FEHLER in /home/schaarst/InfoFiles/prototype:
Kein Objekt für <bin/protoize> in root-Verzeichnis gefunden
Kein Objekt für ...
...
pkgmk: ERROR: Erzeugen von pkgmap aus Prototypdatei nicht möglich
## Packaging war nicht erfolgreich.
sypho%
--- Ende Code ---
Das war wohl nichts. Da habe ich mich wieder mal total unfähig gestellt. Zuerst wollte ich die Ausgabe "Kein Objekt für <...> in root-Verzeichnis gefunden" nicht verstehen. :(
Immer wieder wird es gesagt, notwendigerweise muss man es sich auch ab und zu selbst eingestehen: "Du Vollidiot. Lesen was da steht." ::)
/!\ Nicht schon wieder: "Beitrag hat die max. Länge erreicht (20000 Zeichen)."
... ;)
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln