Installer für Linux

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Linux/Unix verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Was mir bei rpm nicht klar ist:
In allen Tutorials lese ich immer was von Source und Binary Builds. Keine Ahnung was das genau heißt. So wie es aussieht enthält ein rpm meistens den Quellcode der zu installierenden Software? Ich will auf meinem PC die Software installieren und auf den anderen Rechnern NUR die bereits kompilierten Binaries installieren. Geht das mit rpm?

Und diese .spec Dateien: Konfigurieren die wie das .rpm erstellt wird (das ich dann an andere Leute schicke) oder legen die fest was passiert wenn ein .rpm installiert wird?

MarsM schrieb:

Was mir bei rpm nicht klar ist:
In allen Tutorials lese ich immer was von Source und Binary Builds. Keine Ahnung was das genau heißt. So wie es aussieht enthält ein rpm meistens den Quellcode der zu installierenden Software? Ich will auf meinem PC die Software installieren und auf den anderen Rechnern NUR die bereits kompilierten Binaries installieren. Geht das mit rpm?

In der Regel schreibst du eine Konfigurations-Datei, die Festlegt, wie dein Programm übersetzt wird und auf dem System installiert wird. Aus dieser Datei wird dann meistens ein Quell- und ein Binär-Paket erzeugt.

Das Quell-Paket enthält alle Sourcen, die benötigt werden, um die Software zu compilieren. Das Binär-Paket ist das Paket, welches auf den Rechnern installiert wird.

Es hält dich also niemand davon ab, einfach nur die Binär-Pakete weiter zu geben.

MarsM schrieb:

Und diese .spec Dateien: Konfigurieren die wie das .rpm erstellt wird (das ich dann an andere Leute schicke) oder legen die fest was passiert wenn ein .rpm installiert wird?

Soweit ich das weiß, ist die .spec Datei eben jene Konfigurations-Datei.

nman

MarsM schrieb:

So wie es aussieht enthält ein rpm meistens den Quellcode der zu installierenden Software?

Nein, nur Source-RPMs.

nman

MarsM schrieb:

Noch was: Es ist wichtig, dass ich die installierte Software patchen kann. Sprich z.B. von Version 1.1 auf 1.2 patchen - also z.B. eine kleine "Installerdatei", die auf die 1.1 Installation 3 neue Dateien reinkopiert und 2 alte löscht. Geht sowas mit deb oder rpm?

Typischerweise baust du einfach ein frisches Paket, kopierst das in dein Repository und deine User können dann einfach über ihren Paketmanager updaten.

Ich versteh nach wie vor nicht, wie das nun funktionieren soll. In allen Beschreibungen die ich gefunden hab, stand, dass man seinen Quellcode als tgz nach SOURCES kopieren soll. In der .spec schreibt man dann in %pre, wie das tgz entpackt wird und in %build wie der Code übersetzt wird.

Ich habe jedoch keinen Code! Also ich habe ihn schon, aber .rpm soll davon nix wissen. Ich will einfach meinen Code (mit einem recht komplexen Build System) übersetzen, dann mit mehreren Skripten eine finale Ordnerstruktur zusammenbauen. Sagen wir der Ordner heißt Foo/ und er enthält die kompilierten Binaries, Texturen, Configdateien usw usw.

Ich will jetzt einfach nur, dass dieser Ordner Foo im .rpm landet und wenn ein anderer User auf einem anderen PC rpm -U package.rpm macht, dann soll wieder der Ordner Foo/ (samt Inhalt) erzeugt werden.

Wie könnte ich das mit RPM machen?

firefly

welches build system (automake, cmake, bjam) verwendest du?
Falls es cmake ist, dann kannst du mit dem cpack modul auch deps/rpms erstellen lassen (nach dem das projekt übersetzt wurde).
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

MarsM schrieb:

Ich will einfach meinen Code (mit einem recht komplexen Build System) übersetzen, dann mit mehreren Skripten eine finale Ordnerstruktur zusammenbauen.

Dann solltest du in der RPM-Konfiguration einfach nur angeben, wie dein "recht komplexes Build-System" zu starten ist.

Du kannst natürlich in dem Build-Teil des RPMs auch einfach nur hinschreiben, dass es sich die Binär-Dateien aus einem anderen Ordner auf deiner Festplatte kopieren soll, wo du die Dateien schon gebaut hast. Schön wäre das aber nicht.

Wie dem auch sei. Du wirst dich schon genauer mit RPM auseinander setzen müssen, wenn du Pakete bauen willst. Dass dich ein Anfänger-Tutorial nicht dahin bringt, wo du hin willst, ist klar. Du willst etwas, was in der Regel keiner macht. Wenn du RPM verstehst, wird das aber sicher auch kein Problem sein, das so zu machen, wie du willst (s.o.). Aber du musst dich dann nicht über Mehraufwand wundern, wenn du einen anderen Weg als alle Anderen gehen willst.

ProgChild schrieb:

Du kannst natürlich in dem Build-Teil des RPMs auch einfach nur hinschreiben, dass es sich die Binär-Dateien aus einem anderen Ordner auf deiner Festplatte kopieren soll, wo du die Dateien schon gebaut hast. Schön wäre das aber nicht.

Wieso eigentlich nicht? Was ist so schlimm daran ein reines binary rpm aus kompilierten Dateien zu bauen? Wo liegt ueberhaupt der Vorteil, wenn ich alles aus dem Source bau und am Ende ein src.rpm und .rpm hab. Den Kunden schick ich doch letztlich bei Closed Source Software sowieso immer nur das binary .rpm.
Was soll das .src.rpm ueberhaupt bringen bei closed source?

MarsM schrieb:

Den Kunden schick ich doch letztlich bei Closed Source Software sowieso immer nur das binary .rpm.
Was soll das .src.rpm ueberhaupt bringen bei closed source?

Du könntest z.B. einem Kollegen das Source-RPM schicken, falls er es für eine andere Platform, z.B. ARM, übersetzen möchte.