Autor Thema: Übersetzung von der Wiki wie man Pakete baut!!  (Gelesen 4093 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Joe

  • Mit PCLinuxOS holt ihr mehr aus eurem Computer/Lappi raus!
  • Beiträge: 900
Übersetzung von der Wiki wie man Pakete baut!!
« am: 09.April.2015, 13:39:19 »
Hi Leute habe heute mal angefangen den Artikel Package for PCLinuxOS zu übersetzten, werde mich heute ran halten den noch komplett evt fertig zu stellen.

Pakete bauen für PCLinuxOS


Inhaltsverzeichnis des Wiki Artikels Teil I

1.Einführung
2.Grober Überblick
3.Näheres lernen
4.Neue Paketbäcker - Wie man anfängt
5.Aufsetzten der Umgebung
6.Bauen - Schritt für Schritt



Ein Paketbäcker ist das Lebensblut von PCLinuxOS. Der Paketbäcker ist der jenige der PCLinuxOS aktuell hält. Pakete bauen zu lernen ist ein wichtiger Schritt. Neben bei leistet man brauchbare Beiträge zur Wertsteigerung von PCLinuxOS.

Der ganze Prozess ist einfach zu erlernen mit ein bisschen Aufmerksamkeit zum Deteil und Ausdauer. Wenn du in Probleme gerätst, brauchst du nur im IRC oder im Forum anfragen um Hilfe zu erhalten.

1.Einführung

Pakete bauen ist der Prozess von vorbereiteten installierbaren Paketen (Quell Code) zu indivuelle Software. Es ist in Unwort alles damit abzudecken dass nur das erstellen von den Quell Code zu spec Dateien

Um ein erfolgreicher Paketbauer zu werden ist es erforderlich Gedult zu haben. Gib nicht einfach auf. Wenn du kein Erfolg hast versuche es weiter und weiter. Es ist auch sehr wichtig am Anfang viel zu lesen um kein falsches Bild zu bekommen.

Sogar wenn du am Anfang nicht verstehst was du liest oder angeblich tust lese und mache weiter. Die Probleme lösen sich meitens dann beim lesen von selbst.

2.Grober Überblick

Bitte verstehe das dieser Abschnitt nur beabsichtig eine ungefäres Bild von dem dastellt wie ein Paket gebaut wird. Das ist unwahrscheinlich komplett korrekt und daher musst du die Richtigkeit der Informationen selber überprüfen.

Während des Paket bauens wandeln wir original Software/Dateien von Programmierer zu einer Form in die zu verfügung als Download gestellt wird und von den End Benutzern installiert werden kann.

Die Originale Software/Dateien könnte media (Hintergründe, Icons, Sound etc.) oder Software (binär ausführbar, Quell Code) sein. Das häufigste beim RPM Paket bau ist es eine Quelle zu ein installierbaren RPM Paket umzuwandeln für die End Benutzer.

Software von Quell Code - Die meiste Software ist von Menschen geschrieben worden die in der Form einer Programmiersprache geschrieben wurde, wie Assembler, C/C++, Java oder Python. Egal wie der Computer wird immer nur Anweisungen verstehen die in einer Maschinen Sprache geschreiben worden sind die in einer binären Form ist. Also somit müssen wir die Software von Menschen lesbaren  Sprache (Programmiersprache) zu Maschinen Sprache umwandeln. Dies wird compilieren genannt.

Im Falle von C/C++ etc., wird dieser Prozess von Pakete bauen voll endet indem man compiliert.
Java sieht da eher wie eine graue Zone aus man brauch fortgeschrittenes Wissen bevor es zu bytecode wird. Um mehr Informationen über dem zu bekommen lese diese Anleitung - Erstelle ein RPM Paket aus einer Java Anwendung - http://javaworkshop.wordpress.com/2008/10/22/rolling-up-an-rpm-for-a-java-application/
Im Falle von interpretierten Sprachen, wird das voll endet indem man es am Benutzer Computer auswührt.
Daher ist hier die Quelle paketiert wie sie ist.

Das erstellen kann in 3 unterschiedliche Ettappen geschehen:

1. Bei der Original Software: Die meiste kommerzielle Software ist vor gebaut verbreitet.
2. Bei dem Vertreiber: Das ist das was euer Bacon Brigade macht.
3. Beim End Benutzer: Glücklicher Weise brauchen PCLinuxOS Benutzer dies nicht zu machen. Das ist die Standart Methode in Quell basierenden Distributionen.

In unserem Fall ist das Folgende so zu lösen:

1. Die Software wird beschaffen von den Paketbauer.
2. Die Quelle ist entpackt in der Bau Zone und Bau Befehle werden dort ausgeführt um die Ziel Software zu erhalten.
3. Eine Verzeichnis Struktur wird nachgeahmt der Benutzers Computer ist im BUILDROOT erstellt. Die Ziel Software ist nun im BUILDROOT installiert als ob es am Benutzers Computer installiert werden würde.
4. Die Ergebnis Dateien werden aus der BUILDROOT Umgebung heraus genommen und werden zusammen in ein Archive gepackt das Paket genannt wird. Dieses kann man anschließend im /src/rpm/RPMS/i586 oder x64 finden.
5. Eine Kopie des Quell Codes und der .spec Datei (wird gebraucht um das Paket zu erstellen) wird in /src/rpm/SPRM gespeichert. Das ist das was der Betreuer von PCLinuxOS benutzt, um das selbe Paket zu erstellen und fügt es in der Offiziellen Repo nach Qualitäts Prüfungen.

Software binär und media - Es ist ein bisschen anders wenn man zu binären Paketen und media kommt, da diese immer in compilierter binären Form vorkommen. Meistens brauchen diese nur in den richtigen Pfad platziert zu werden.

3.Näheres lernen

Bitte lese diese komplette Anleitung. Teile dieser Anleitung sind wörtlich oder kaum abgeänderte Beiträge von Forum Mitgliedern bezeichnet. Der hohe Level von Wissen der respektvollen Autoren, kann zunächst einschüchtern. (Ich hatte die selbe Erfahrung). Nun lest den Rest der Anleitung.


?Zu beginn solltest du lernen etwas erneut zu bauen was in unserer Repo vorhanden ist. Suche nach Software die weniger als 1 MB Größe aufweißt zunächst.

Als nächstes solltest du versuchen etwas zu bauen ähnliches bauen von dir selbst. Versuche es mit sehr einfachen Dateien (nur 1 oder 2 Dateien).
Als nächstes solltest du versuchen etwas zu aktualisieren was in der Repo ist. (Du musst zuerst die Version Nummern lernen von ein existierendes Paket und vergleiche es mit den von den offiziellen Webseiten, um zu wissen welche überhaupt aktualisiert werden können.)

Nun kannst du es versuchen Software zu paken die nicht in der Repo ist oder auf ein Paket dessen Lösung du noch nicht aus der Repo bezogen hast.

Sobald du dass kannst, versuche Bibliotheken zu paken, nachdem du diese zunächst verstanden hast.

Nun könntest du dich an complexere und interlinked Paketen versuchen. Wie zum Beispiel komplette Desktop Umgebungen, wine etc.

In diesem Level, könntest du versuchen binäre Software wie Grafik Treiber zu paken etc.

4.Neue Paketbäcker - Wie man anfängt


Bekomme eine Vorstellung von unsere Repo wie diese aufgesätzt wurde, indem du dieses ließt Repo und Sectionen und Spiegel Server

Beitrag vonNeal im Forum

Gehe zu: http://ftp.nluug.nl/pub/os/Linux/distr/pclinuxos/pclinuxos/ und scrolle runter zu den SRPMS.(*) sectionen. Beim klicken auf diesem wird die Section geöffnet, dort findest du SRPMs für PCLinuxOS.
Diese sind die besten src.rpms um Pakete bauen zu erlernen auf den PCLinuxOS Standart.
Betrachte diese genauer und wie die spec Dateien geschrieben wurden.

Du solltest nicht mit einer SRPM von einer anderen Distribution starten, da diese Änderungen voraussetzten die du noch nicht bewältigen kannst. Diese benutzen meistens verschiedene Namen, so das die Abhängigkeiten mit anderen Namen markiert sind als in PCLinuxOS.
Diese müssen in unterchiedlichen Verzeichnisse installiert werden, das wiederum Schwierigkeiten mitbringt.

Das wichtigste ist das du damit startest PCLinuxOS Pakete neu zu paken, weiter machen musst du mit aktualisieren von unseren Paketen. Und nur nachdem du gelernt hast wie man ein PCLinuxOS Paket baut wirst du in der Lage sein ein SRPM zu convertieren von sonst wo.

Du kannst auch andere Spiegel Server benutzen anstelle von NLUGG.

5.Aufsetzten der Umgebung

Folge diese Schritte:

Lade dir die KDE MiniMe oder LXDE Mini Geschmacksrchtung auf eine Seperate Partition.

Installiere pkgutils-kde oder pkgutils-thunar die automatisch auch pkgutils installieren.

Wähle den Benutzer Name in dem du auf ihn klickst wenn du danach gefragt wirst welchen Benutzer du als Paketbäcker einstellen möchtest. Alle die Pakete werden in dem src Verzeichnis erstellt unter dem Benutzers /home.
Hinweis: Selbst wenn nur ein Benutzer in dieses System installiert ist. ist es erforderlich auf ihn zu klicken und markieren den Nutzername. Sonst wird der Prozess abgebrochen und du musst mit den Befehl mkrepo im Terminal ausführen um diesen Prozess zu voll enden.

Vermeide es spezielle Zeichen zu verwenden von den Benutzer der als Paketbäcker ausgewiesen werden soll.

Wenn alles richtig verläuft, wird dein home Verzeichnis /home/xxxx wobei xxxx für den Paketbäcker steht ein neuen Ordner bekommen haben mit den Namen src. Wenn du in dem Ordner gehst, sollten folgende Inhalte enthalten sein apt rpm tmp.
apt ist deine Repo mit den selbst gebauten Paketen.
rpm ist dort wo dein Paketbau Prozess statt findet.
tmp ist ein Temporäres Verzeichnis.

/home/xxxx/src/rpm/RPMS
speichert erstellte .rpms entweder i586 oder x86_64 (hängt ab welche System Architektur du benutzt.)

/home/xxxx/src/rpm/SOURCES speichet deine Quellen müssen in tar.xz sein.

/home/xxxx/src/rpm/SPECS speichert deine .spec Dateien die du brauchst zum bauen des Paketes.

/home/xxxx/src/rpm/SRPMS
speichert deine Schluss endlichen .srpms. Diese werden benötigt wenn du erfolgreich im Bauen warst, teste es anschließend und stelle sicher das es Bug frei läuft, um es hoch zu laden zum PCLinuxOS Betreuer.

Im /home/xxxx sind 2 versteckte Dateien mit den Namen .rpmmacros und .rpmrc

6.Bauen - Schritt für Schritt


Dieser Prozess beschäftigt sich damit wie man ein PCLinuxOS Paket baut. Wir brauchen dazu folgendes:

Quelle - Ist verfügbar zum herunterladen von der Original Entwickler Webseite oder in den .srpm Link der im oberigen zur show gestellt wurde. Es kann verfügbar als tar.gz oder tar.xz Format verfügbar sein oder in ein anderen kompremierten Format. Wie immer PCLinuxOS schreibt vor, dass diese in tar.xz konvertiert werden. Dies wird gemacht indem man ein rechts Klick auf der heruntergeladenen Datei macht und es zu der tar.xz kompression Kompremiert.
Nun diese Quell Datei im tar.xz Format muss in /home/xxxx/src/rpm/SOURCES Verzeichnis verschoben werden.

Spec - Dies ist die Datei die beinhaltet die Anweisungen über den aktuellen Prozess vom Paket bau. Es kann eines vom beiden sein, entweder ein neues oder ein aktualisiertes Paket von der älteren .srpm Version was in unserer Repo existiert.

Abhängigkeiten - Jedes Paket was gebaut wird braucht die Existens von anderen Paketen. Abhängigkeiten können entweder build-time oder run-time sein. Build-time Abhängigkeiten sind gebräuchlich in der Form von -devel Paketen während run-time Abhängigkeiten gebräuchlich in der Form von Bibliotheken oder anderen Paketen. Abhängigkeiten können feststehend von lese oder Release Hinweise von den Entwickler sein, Readme.txt oder equivalent Text Dateien in den Quell Packet oder bei den älteren .spec Dateien.
Ein einfacher Weg Abhängigkeiten zu installieren ist ein rechter Klick auf der .spec Datei und wähle Installiere Abhängigkeiten aus. Als Alternative, eine macht eine Liste von Abhängigkeiten und installiere diese einzeln für einzeln mithilfen von Synaptic oder benutze apt-get install von der Befehlszeile.

Wenn du ein Paket neu baust von .srpm, müsstest du entweder rechts klicken auf dem .srpm und Installiere vor bauen auswählen oder gehe in der Befehlszeile, navigiere mithilfe von cd /../.. zu dem Verzeichnis wo die .srpm enthalten ist hin und schreibe:

rpm -ivh namedespaketes.srpm
Ist dies einmal fertig gestellt, kannst du mit ein rechts Klick auf der .spec Datei Build all oder Build all, log file um das erstellen des Paketes zu starten. Als Alternative, navigiere zu der /home/xxxx/src/rpm/SPECS  Verzeichnis und schreibe:

rpmbuild -ba namedespaketes.spec
Es kann ein bisschen dauern bis das Paket fertig gebaut wurde, dabei hängt es von der Größe und der Komplizität des Paketes ab, und klar auch von den Power deines Computers etc.

Ein rechts Klick build öffnet eine spezielle Shell mit der man nicht eine completion erledigt bekommt. Der Ende des bau Prozesses wird mit einem exit 0 markiert in der letzten Zeile.
Wenn der Bau Prozess von der Befehlszeile gestartet wurde, wirst du automatisch wieder zurück zu der Eingabe Aufforderung geschickt wenn der Prozess erfolgreich war.

Betrachte die Ausgabe von dem Paket Bau sorgfältig. Generell wenn ein WARNING ausgegeben wird, crasht es nicht den kompletten Bau Prozess, aber spätere Probleme mit diesem Paket sind vorprogrammiert. Wie immer jeder ERROR wird dafür sorgen das der Bau Prozess automatisch gestoppt wird. Notiziere dir Fehler Ausgaben um eventuell nachher bessere Analyiesen durch führen zu können.

Führe gbd von der Befehlszeile aus, um deine eigene Repo zu aktualisieren und danach installiere dein Paket mithilfe von Synaptic und stelle sicher das dieses Paket funktioniert ohne Probleme.

Übersetzt von Joe
« Letzte Änderung: 12.Februar.2016, 20:51:48 von Joe »

Offline Joe

  • Mit PCLinuxOS holt ihr mehr aus eurem Computer/Lappi raus!
  • Beiträge: 900
Re: Übersetztung von der Wiki wie man Pakete baut!!
« Antwort #1 am: 09.April.2015, 16:19:21 »
Inhaltsverzeichnis des Wiki Artikels Teil II

  7.Sammeln von Informationen
  8.Verhaltensregeln
  9.Abhängigkeits Management
10.Paketbäcker Tipps und Hinweise
11.Hinweise
12.Fehler und Warnungen


7.Sammeln von Informationen

Bevor oder während du ein Paket erstellst oder ein Fehler Bericht erstellste, musst du einige Informationen bezüglich Einstellungen. Optionen etc. haben. Es gibt viele Möglichkeiten wo du mehr Informationen her bekommst und die Herkunft hängt ebenfalls von der Sprache ab, typ von Paket etc.

Homepage - Wenn das Paket eine gute Betreuer homepage besitzt, es ist dein erster Punkt den du schreiben musst.

Quelle - Die Quelle das Kompremierte tar Paket oder das Verzeichnis beinhaltet Dateien wie README, INSTALL, CHANGELOG welche auch gute Informationen beinhalten.

configure.ac -
Diese Datei könnte sehr wichtige Informationen über Abhängigkeiten bereithalten.

./configure --help - Die verfügbaren Optionen für das Bauen können weitere Informationen ermitteln indem man dieses Paket in einem Verzeichnis extrahiert und anschließend im Terminal ausführt.

8.Verhaltensregeln

Ein ein bisschen abgeänderter Forum Beitrg von Texstar:

Bennene deine specdatei - pclos-name-von-den-paket.spec (Beispiel: pclos-doxygen.spec)
Dies macht es einfacher ein Paktet zu aktualisieren und wenn du auf ein Bau Fehler stößt. Du kannst andere Quell Packete von anderen Distributionen installieren, indem du deren spec Dateien mit unseren vergleichst, um zu sehen ob sie ein Patch oder eine andere Bau Option zu machen um die neue Version zu erstellen.

Convertiere deine Quelle zu einer tar.xz von tar.gz oder tar.bz2

Die öffentlichen Server haben nicht unlimitierte Bandbreite. Beim erneuten kompremieren deiner Quelle mit tar.xz wirst du eine viel kleinere SRPM generieren. Dies spart Platz auf den Spiegel Servern und macht das hochladen von den SRPMs schneller als wenn diese es nicht wären.

Nutze richtige Versionen von dein Paket Release

Wenn dies ein neues Paket ist gehe zu der PCLinuxOS Repo sogar wenn es auf einer anderen Distributions spec Datei basiert als dein Release Makro für PCLinuxOS ist %mkrel 1

Erstelle ein komplettes Protokoll (changelog)

Dies gibt Informationen drüber wann in Paket gebaut wurde, wer es gebaut hat, ein E-Mail Kontakt des Paketbäckers, die Version Nummer und eine Zusammenfassung von dem was du mit dem Paket gemacht hast. Wenn du ein Paket importierst von einer anderen Distribution brauchst du nur in den Zusammenfassungsbereich basiert auf der Original spec Datei von fedora, Opensuse, mdv etc.....
Beispiel:
- Mon Mar 28 2011 Texstar <texstar at gmail.com> 1.7.4-1pclos2011
- 1.7.4
- add requires for new glibc

gcc/glibc Aktualisierungen brauchen weitere Abhängigkeiten

Wenn du gcc/glibc aktualisierst musst du die folgenden spec Dateien addieren um die Benutzer aufzufordern die beiden 2 folgenden Pakete zu aktualisieren um dafür zu sorgen das die neuen Programme mit gcc 4.5.2 compiliert werden.

Erfordert: glibc >= 2.12.1
Erfordert: libstdc++6 >= 4.5.2

Neal vom Forum schrieb:

Teste dein Paket befor du dieses hochlädst.

Wenn dein Paket Bata Software ist, stelle Sicher das dies auch dabei steht.

Wir werden es zuvor erst in der Testing Section zu verfügung stellen.

Baue niemals Alpha Software!!!

Am Ende überprüfe ob das Paket eine Aktualisierung zu verfügung stellt.
Wenn dem so ist, erstelle ein neues Paket, teste es und reiche es ein.

Vergesse nicht dein Protokoll Eintrag gegebenen Falls zu ändern (changelog). Sei sicher das du Tag, Datum (Monat und den Tag nummerierst von den Monat) und das Jahr von den Tag an den du das Paket gebaut hast. Addiere deine Informationen zu den Eintrag. Benutze nicht die Informationen von den vorherigen Paketbäcker.

9.Abhängigkeits Management


Ein leicht geänderter Forum Beitrag von TerryN im Forum.

Viele Leute die neu am Pakete bauen sind denken dass das Abhängigkeits Management ist nur über Provides: und Requires: Einträge in der spec Datei. Diese sind nur ein Teil von der Geschichte, da rpm automatisch Abhängigkeiten generiert als Teil von den rpmbuild Prozess. Dies ist lösbar durch 2 Skripte find-provides und find-requires welche neben bei laufen währende des Bau end Prozesses.

· find-provides:


Dieses Skript untersucht alle Dateien in den %files Liste und wenn irgendeine teilende Bibliothek findet die soname von der lib ist addiert zu der List von capabilities zu verfügung gestellt von den rpm. Dies meint das wenn einanderes Paket von der geteilten Bibliothek abhängt. Diese können ausgewählt werden von apt oder Synaptic um die Abhängigkeit zu frieden zu stellen.

Sei sehr vorsichtig wenn eine vorbereitete Paket Anwendung die SOURCES enthält und eine vor erstellung der Bibliotheken zu addiert wird und du kannst diese finden in dein Paket indem du die auswählst als schein Abhängigkeiten. Schlechter noch dies kann zu instabilität führen wenn diese Bibliotheken gebraucht werden zu einer anderen Anwendung (da diese nicht in PCLinuxOS erstellt wurden).
Um das zu vermeiden kannst du Autoprov: No hinzufügen die Zusammenfassungs Section von der spec Datei (das ist dort wo die Provides/BuildRequires/Requires/Obsolete Einträge sind) für diese Typen von Pakete (und nur diese Typen von Paketen!!)

Autoprov: No
Die Dokumentation kann hier eingelesen werden.

· find-requires:

Dieses Skript untersucht alle die Dateien in den %files Prefix und führt effektiver Weise ein ldd aus auf jeder Ausführbaren Datei, um zu sehen die Liste der erforderlichen Fähigen des rpms zu sehen und es wird es lösen wenn das rpm ist installiert.

Noch einmal vor gebildete binäre SOURCE können Probleme verursachen wie die Bemärkung sonames diese können nicht gelöst werden von ein existirendes Paket aus der Repo.
Ein Beispiel wird zeigen den SOURCE beinhaltet binären für mehrere Architekturen (hier das Beispiel.

Devel Abhängigkeiten:

Dort ist eine weitere doppelte mit den geteilten Objekten welche als System genutzt werden geteilte Bibliotheken (sie sind andere Benutzt für .so Dateien). Der Bau Vorgang wird 3 „Kopien“ produzieren von der lib (zur Zeit nur 1 ist die reale Datei die anderen sind Links, aber die interessieren zunächst nicht):
/usr/lib/libxyz.so.1.2.3
/usr/lib/libxyz.so.1
/usr/lib/libxyz.so

Die erste beiden (die versionierten Dateien) sind erforderlich für runtime und sollten  in dem Haupt Paket sein. Die dritte (lixxyz.so) wird nur von den Linker erfordert wenn diese Anwendung gegen die geteilten Bibliotheken und sollten deshalb in den -devel Paket sein (mit den Header Dateien).

RPM ist schlau genug um das zu wissen und generiert „devel“ provides/requires für diese Datei.
Deshalb wenn du die unversionierte .so in dem Haupt Paket. Das automatische Abhängigkeits Management wird eine „devel“ generieren und zu verfügung stellen:

[terry@localhost ~]$ rpm -q --provides kde-workspace-core | grep devel
devel(libkwinglesutils) 
devel(libkwinglutils) 
devel(liboxygenstyleconfig) 
devel(libpowerdevilconfigcommonprivate) 
devel(libpowerdevilui)
und deshalb die devel Abhängigkeiten:

[terry@localhost ~]$ rpm -qR kde-workspace-core | grep devel
devel(libdl) 
devel(libEGL) 
devel(libgcc_s) 
devel(libGL) 
devel(libGLESv2) 
devel(libICE) 
devel(libkdecore) 
devel(libkdeui) 
devel(libkephal) 
devel(libkwineffects) 
devel(libm) 
devel(libpowerdevilcore) 
devel(libpowerdevilui) 
devel(libQtCore) 
devel(libQtDBus) 
devel(libQtGui) 
devel(libQtSvg) 
devel(libSM) 
devel(libstdc++) 
devel(libX11) 
devel(libXau) 
devel(libXdmcp) 
devel(libXext) 
devel(libXft) 
devel(libXpm
und diese devel Abhängigkeiten haben ihre eigene Anhängigkeiten etc. etc. Dies könnte resulutiren in einem schmalen Betrag von unerforderlichen Paketen und andere „Bau“ Pakete dasein installiert auf Systeme die nicht benutzt werden um Software zu bauen. Dies kann viel Speicherplatz in Anspruch nehmen und macht Dinge wie remastern schwerer.

Wenn du sicher bist das niemals ein Link oder Bau gegen eine Bibliothek ist kannst du vermeiden das a -devel Subpakete entweder die .so am Ende von %install section löscht.

rm -f %buildroot/%{_libdir}/libxyz.so
Oder benutze ein %exclude für die Datei in der %files Liste.

%files
...
%exclude %{_libdir}/libxyz.so

aber wenn dort irgendow ein Zweifel besteht, benutze ein -devel package.

Zur Zusammenfassung, große Aufmerksamkeit ist erforderlich bei dem managen von System geteilten Bibliotheken. Es ist kompliziert, langweilig und bestimmt nicht glamourös aber es ist erforderlich die Repo davor zu bewahren in Blut und Chaos auf zu gehen.

10.Paketbäcker Tipps und Hinweise

Einführungen in der specific öffentlichen Kategorien von Paketen ist hier erleutert: http://www.pclinuxoshelp.com/index.php/Handling_package_categories

Dies ist ein laufendes Forum Thema mit viele wichtigen Leckerbissen von Informationen zum Thema in dein Paketbau: http://www.pclinuxos.com/forum/index.php/topic,101266.0.html

Alte und neue Bibliotheken und wie deren aktualisierungs Verhalten ist: http://www.pclinuxos.com/forum/index.php/topic,110765.0/topicseen.html

11.Hinweise

SRPMs: http://ftp.nluug.nl/pub/os/Linux/distr/pclinuxos/pclinuxos/srpms/SRPMS.pclos/

Die wichtigkeit von der orginisation kann nie über betont werden. Notiere dir alles. Es wird dir helfen mit der Arbeit in der du gerade tätig bist oder wenn du nachher weiter machen willst.

Baue niemals Pakete als root.

Halte deine Paket Umgebung immer aktuell. Damit ist gemeint das man eine volle Aktualisierung durchführen muss befor man ein Prozess beginnt und löscht irgendwelche Abhängigkeiten oder Bibliotheken instaliert bevor einer bestimmten Arbeit.

Wenn du rpm -ivh namedespaketes.srpm ausführst bommst du eine Beschwerde über den Benutzer Neal does not exist or something like that. Es ist weil der Original Packetbäcker nicht du bist sondern Neal. Verzweifel nicht.

Aktiviere die Components Section von Synaptic dadurch wird es für dich viel einfacher die Section zu lokalisieren unter der die erforderliche .srpm ist in der Repo.

Wenn du von einer Befehlszeile arbeitest und du möchtest alle Ausgaben festhalten von den Bau Verfahren in einer Text Datei für einfache Analysen, führe diesen Befehl aus:
daniel - http://www.pclinuxos.com/forum/index.php/topic,109252.msg933761.html#msg933761

rpmbuild -ba pclos-nameofpackage.spec > ~/Desktop/nameofpackage.spec.log 2>&1
Installere ccache. Dies beschleunigt deine erfolgreichen neu Bauten. Archie - http://www.pclinuxos.com/forum/index.php/topic,109252.msg934066.html#msg934066

Wenn du Qt und KDE baust, brauchst du cmake, die Abhängigkeit wurde nicht indicitiert von der spec Dateu und cmake is nunhier, kdelibs-devel.
Archie - http://www.pclinuxos.com/forum/index.php/topic,109252.msg934066.html#msg934066

./autogen.sh wird gebraucht von der ersten Zeile der Bau Section um configure und make Dateien zu generieren also dadurch kann das Paket erstellt weren. Gewöhnlicher weise für Software svn oder git. Manchmal wirde es gebraucht da nicht zu den Bau Bibliotheken verlinkt wird. Texstar - http://www.pclinuxos.com/forum/index.php/topic,112517.msg962671.html#msg962671

12.Fehler und Warnungen

Es kommt selten vor das ein Paket heine Fehler Ausgaben beim bauen meldet. Hier sind ein paar von diesem, und wie man mit ihnen umzugehen hat.

file not found by glob

make: *** No rule to make target `install'. Stop.

Dies scheint im Falle des Backetbäckers das eine seperates Unterverzeichnis erstellt werden muss um die config/build Dateien zu erstellen. Es wird build genannt aber der exacte Name kann man heraus finden imdem man die build log liest. Dies wird gefixt indem man -C nameofsubdirectory hinzu addiert um die make install Makro in %install section von der .spec Datei. TerryN - http://www.pclinuxos.com/forum/index.php/topic,114540.msg976443.html#msg976443

Übersetzter Joe
« Letzte Änderung: 09.April.2015, 21:32:49 von Joe »

Offline pinguin4488

  • Administrator
  • *
  • Beiträge: 980
  • PCLinuxOS....weil es einfach besser ist.
Re: Übersetztung von der Wiki wie man Pakete baut!!
« Antwort #2 am: 09.April.2015, 19:56:13 »
ist auf Daniel seine Seite Hier
alles schön die Reihe nach aufgelistet.

Albert
   

Nur der Fragenden Menschen kann geholfen werden.

Offline Leiche

  • Global Moderator
  • *
  • Beiträge: 619
  • Gott weiß, ich bin kein Engel
    • Tipps und Tricks
Re: Übersetztung von der Wiki wie man Pakete baut!!
« Antwort #3 am: 09.April.2015, 21:02:33 »
Immer schön eine weitere Übersetzung zu sehen, zeigt dass das Thema doch aktueller ist den jeh...

Regards
Daniel

martinh

  • Gast
Re: Übersetztung von der Wiki wie man Pakete baut!!
« Antwort #4 am: 10.April.2015, 11:13:05 »
Immer schön eine weitere Übersetzung zu sehen, zeigt dass das Thema doch aktueller ist den jeh...

Regards
Daniel

+1 ,und super-gut uebersetzt :)

Offline Joe

  • Mit PCLinuxOS holt ihr mehr aus eurem Computer/Lappi raus!
  • Beiträge: 900
Re: Übersetztung von der Wiki wie man Pakete baut!!
« Antwort #5 am: 10.April.2015, 12:05:22 »
Guckt mal wenn ihr hier im Thema seit nach links auf euren Profil dort seht ihr positiv und negativ und darüber karma, so kann man auch die Bewertung abgeben ohne +1 und so, oder?