Revision [1325]

Last edited on 2009-04-05 16:33:25 by ToniCE
Additions:
[[http://asturio.gmxhome.de/software/slackselect/i.html slackselect ]]
Deletions:
[[http://asturio.gmxhome.de/slackselect.html slackselect ]]


Revision [746]

Edited on 2006-10-03 14:15:30 by MaschinenHans [Fehler in der Verzeichnisangabe geändert (überschüssiges "/usr" gelöscht)]
Additions:
##make install prefix=/tmp/build##
##make install DESTDIR=/tmp/build##
Deletions:
##make install prefix=/tmp/build/usr##
##make install DESTDIR=/tmp/build/usr##


Revision [735]

Edited on 2006-09-24 19:31:07 by TuxXut [Fehler in der Verzeichnisangabe geändert (überschüssiges "/usr" gelöscht)]
Additions:
Die Originalversion dieses Textes ist hier zu finden ( Vielen Dank an Akron ): http://www.slackforum.de/forum/index.php?t=msg&th=346
Als allererstes sollte man verstehen, was genau ein Slackware-Packet ist. Wie die Dateiendung schon vermuten lässt, handelt es sich um nichts weiter als einen Tarball - eine gezippte Sammlung von Dateien die sauber in (mehr oder weniger) übersichtlichen Ordnern gepackt worden sind. Wie beim kompilieren von Source-Code kann man diese an jeder beliebigen Stelle extrahieren. Tools wie "installpkg" machen nicht viel mehr, nur mit dem Unterschied, das ein Softwarepacket stets von der Wurzel / aus entpackt wird. Das bringt uns zu der Schlussfolgerung, dass wir, um Software zu installieren, auch einfach folgende Schritte ausführen könnten:
Genug der grauen Theorie, wir wollten schliesslich Pakete schnüren. Ich gehe an dieser Stelle davon aus, dass ihr mit dem eigentlichen kompilieren und installieren von Source-Code vertraut seid. Falls nicht, lest ihr das bitte im entprechenden Source-Code-HOWTO nach.
Als allererstes benötigen wir einen kleinen Arbeitsbereich, im folgenden Beispiel verwende ich /tmp/build. Natürlich ist auch jeder andere Ordner gültig, so lange er nur leer ist.
Wenn wir selbst kompilierte Software benutzen wollen, müssen wir deren Tarball ebenfalls entpacken, z.B. in /usr/local/src
An dieser Stelle wäre nur das übliche ./configure && make && make install an der Reihe. Bitte nicht so voreilig, hier setzt der erste wichtige Schritt ein. Im folgenden Beispiel gehe ich davon aus, dass ihr das ./configure-Script ohne zusätzliche Parameter startet, da dieses eh immer variert. Solltet ihr welche benötigen - rein damit.
Damit wird eigentlich nur bestimmt, dass die Software vom Wurzelverzeichniss aus installiert werden soll. Wenn ihr eigene Programme lieber in /usr/local habt, soll das euch überlassen sein. Das ganze hat aber einen kleinen Nachteil, welcher aber von eurer persönlichen Partitionsordnung abhängt. Details dazu im Partitons-HOWTO.
Mit dieser Anweisung haben wir das Kopieren in den Verzeichnissbaum entscheidend umgelenkt. Sämtliche Dateien sind jetzt im Ordner /tmp/build/ gelandet und bilden dort den normalen Verzeichnissbaum nach. Wichtig dabei ist, das sie eigentlich davon nichts mitgekriegt haben. Sollten bei der Installation Symlinks angelegt worden sein, zeigen sie auf die selbe Stelle, an die sie spa:ter zeigen sollen - na:mlich nicht innerhalb von /tmp/build, sondern auf den entprechenden Platz im Root.
Deletions:
Die Orginalversion ist dieses Textes ist hier zu finden ( Vielen Dank an Akron ): http://www.slackforum.de/forum/index.php?t=msg&th=346
Als allererstes sollte man verstehen, was genau ein Slackware-Packet ist. Wie die Dateiendung schon vermuten lässt, handelt es sich um nichts weiter als einen Tarball - eine gezippte Sammlung von Dateien die sauber in (mehr oder weniger) übersichtlichen Ordnern gepackt worden sind. Wie beim kompilieren von Source-Code kann man diese an jeder beliebigen Stelle extrahieren. Tools wie "installpkg" machen nicht viel mehr, nur mit dem Unterschied, das ein Softwarepacket stehts von der Wurzel / aus entpackt wird. Das bringt uns zu der Schlussfolgerund, das wir um Software zu installieren, auch einfach folgende Schritte ausführen könnten:
Genug der grauen Theorie, wir wollten schliesslich Packete schnüren. Ich gehe an dieser Stelle davon aus das ihr mit dem eigentlich kompilieren und installieren von Source-Code vertraut seit. Falls nicht, lest ihr das bitte im entprechenden Source-Code-HOWTO nach.
Als allererstes benötigen wir einen kleinen Arbeitsbereich, im folgenden Beispiel verwende ich /tmp/build. Natürlich ist auch jeder andere Ordner gültig, so lange es nur leer ist.
Wenn wir selbst kompilierte Software benutzen wollen, müssen wie deren Tarball ebenfalls entpacken, z.B. in /usr/local/src
An dieser Stelle wäre nur das übliche ./configure && make && make install an der Reihe. Bitte nicht so voreilig, hier setzt der erste wichtige Schritt ein. Im folgenden Beispiel gehe ich davon aus, das ihr das ./configure-Script ohne zusätzliche Parameter startet, da diese eh immer variert. Solltet ihr welche benötigen - rein damit.
Damit wird eigentlich nur bestimmt, das die Software vom Wurzelverzeichniss aus installiert werden soll. Wenn ihr eigene Programme lieber in /usr/local habt, soll das euch überlassen sein. Das ganze hat aber einen kleinen Nachteil, welcher aber von eurer persönlichen Partitionsordnung abhängt. Details dazu im Partitons-HOWTO.
Mit dieser Anweisung haben wir das kopieren in den Verzeichnissbaum entscheidend umgelenkt. Sämtliche Dateien sind jetzt im Ordner /tmp/build/ gelandet und bilden dort den normalen Verzeichnissbaum nach. Wichtig dabei ist, das sie eigentlich davon nichts mitgekriegt haben. Sollten bei der Installation Symlinks angelegt worden sein, zeigen sie auf die selbe Stelle, an die sie spa:ter zeigen sollen - na:mlich nicht innerhalb von /tmp/build, sondern auf den entprechenden Platz im Root.


Revision [667]

Edited on 2006-08-04 17:32:12 by MreimeR [Nachtrag zu Paket-Namen]
Additions:
Zum Dateiname nach makepkg: "foo" wäre der Name und "1.0" die Version des "verpackten" Programms. Der Teil "`uname -m`" wird automatisch mit dem "Prozessor-Typ" (z.B. i686) ersetzt. Das "1nick" ist in Original-Paketen als Revisions-Nummer gedacht. Bei selbstgemachten Paketen ist es sinnvoll, der Revisionsnummer auch deinen Nicknamen, oder die Initialen des Paketerstellers, anzuhängen. Format ist also immer:
Deletions:
Zum Dateiname nach makepkg: "foo" wäre der Name und "1.0" die Version des "verpackten" Programms. Der Teil "`uname -m`" wird automatisch mit dem "Prozessor-Typ" (z.B. i686) ersetzt. Das "1nick" ist in Original-Paketen als Revisions-Nummer gedacht. Bei selbstgemachten Paketen ist es sinnvoll der Revisionsnummer auch dein Nicknamen oder die Initialen des Paketerstellers anzuhängen. Format ist also immer:


Revision [666]

Edited on 2006-08-04 17:30:41 by MreimeR [Nachtrag zu den Paket-Namen]
Additions:
##makepkg foo-1.0-`uname -m`-1nick.tgz##
Zum Dateiname nach makepkg: "foo" wäre der Name und "1.0" die Version des "verpackten" Programms. Der Teil "`uname -m`" wird automatisch mit dem "Prozessor-Typ" (z.B. i686) ersetzt. Das "1nick" ist in Original-Paketen als Revisions-Nummer gedacht. Bei selbstgemachten Paketen ist es sinnvoll der Revisionsnummer auch dein Nicknamen oder die Initialen des Paketerstellers anzuhängen. Format ist also immer:
$NAME-$VERSION-$PROZESSOR-$REVISION.tgz
Deletions:
##makepkg foo.tgz##


Revision [322]

Edited on 2006-01-07 13:24:40 by MreimeR [Nachtrag zu den Paket-Namen]
Additions:
[[CategoryTutorials]]
Deletions:
[[(cat)CategoryTutorials]]


Revision [280]

Edited on 2006-01-02 22:00:47 by MreimeR [Nachtrag zu den Paket-Namen]
Additions:
[[(cat)CategoryTutorials]]
Deletions:
CategoryTutorials


Revision [270]

Edited on 2006-01-02 20:34:52 by MreimeR [Nachtrag zu den Paket-Namen]
Additions:
==Kategorien==
CategoryTutorials


Revision [31]

The oldest known version of this page was created on 2005-08-21 01:05:30 by ToniCE [Nachtrag zu den Paket-Namen]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki