4. Programm zu .deb- und .rpm-Paket machen, sodass es auf anderen PCS läuft

Programm zu .deb- und .rpm-Paket machen, sodass es auf anderen PCS läuft

  • A

    Sorry, mein Fehler habe C mit Java verwechselt.

    Ich habe auch eine Gebrauchsanweisung für .ipkg-Pakete.

    http://dream.reichholf.net/wiki/Howto:IPK_Pakete_erstellen

    0
  • S

    Entweder habe ich es übersehen oder da steht der eigentlich Kern nicht dabei: Wie mache ich aus meinem Quellcode "weiterreichbare" Daten?

    Und warum soll der Link oben nur für Java funktionieren, das habe ich da nirgendwo gelesen 😕.

    0
  • A

    Warum ist es denn möglich, bei mir kompilierte Anwendungen weiterzugeben? Ich dachte, das kompilierte Programm bestünde aus Systemabhängigem Code?

    -> Sorry, mein Fehler habe C mit Java verwechselt

    ---

    Über die Pakete kann man die Datei weiterreichen, das könnte man aber auch per .zip Datei machen.

    An wen willst du die Datei weiterreichen, an alle im I-net oder an einem Freund?

    Bei ersteren suche ich dir dann kurz mal die Seite raus, wo du dann das .deb-Paket z.B. Synaptik Paketmanager eintragen kannst

    0
  • N

    Stiefel2000 schrieb:

    Mir ist aufgefallen, dass es einige Programme gibt, die in Form einer .bin- oder .run-Datei vertrieben werden. Ist es möglich, soetwas unkompliziert und automatisiert zu erstellen?
    Ich selbst nutze Ubuntu, ein .deb-Paket wäre daher auch ganz interessant. Aber da den .bin-Versionen die Distribution egal zu sein scheint, will ich mich nicht auf .deb festlegen.

    bin und run sind keine eigenen Paketformate, sondern einfach nur Endungen, die darauf hinweisen sollen, dass man die entsprechenden Programme ausführt. Dahinter verbirgt sich dann meistens ein Shellscript, das Dateien herumkopiert und Pfade setzt oder so.

    Sinnvoller sind entsprechende Distro-Pakete. Wie man Pakete für Debian (und somit auch Ubuntu) erstellt, wird zB. hier erklärt:
    http://magazin.c-plusplus.net/artikel/Softwareinstallation f�r das Debian System

    Entweder habe ich es übersehen oder da steht der eigentlich Kern nicht dabei: Wie mache ich aus meinem Quellcode "weiterreichbare" Daten?

    Hm? Du kompilierst sie, die entsprechende Binary kannst Du dann auf anderen Rechnern ausführen, sofern dort alle Dependencies (shared libraries etc.) Deines Programms vorhanden sind. Dass diese Dependencies vorhanden sind, lässt sich am leichtesten mit einem Distro-Paket sicherstellen, weil Du da die Dependencies auflisten kannst und sie automatisch installiert werden.

    0
  • S

    nman schrieb:

    bin und run sind keine eigenen Paketformate, sondern einfach nur Endungen, die darauf hinweisen sollen, dass man die entsprechenden Programme ausführt. Dahinter verbirgt sich dann meistens ein Shellscript, das Dateien herumkopiert und Pfade setzt oder so.

    Das war mir schon klar, aber scheinbar kann man es damit ja schaffen, Dateien zu erstellen, die auf diversen Linux-Systemen per einmaliger Ausführung ein Programm installieren. Sowas möchte ich haben, daher der Hinweis.

    nman schrieb:

    Sinnvoller sind entsprechende Distro-Pakete.

    Das klingt nach viel Aufwand, wenn ich nicht nur Ubuntu versorgen will, deshalb gefällt mir der Gedanke nicht. Aber die von dir verlinkte Anleitung schaue ich natürlich an, zuviel kann man ja nicht wissen.

    nman schrieb:

    Hm? Du kompilierst sie, die entsprechende Binary kannst Du dann auf anderen Rechnern ausführen, sofern dort alle Dependencies (shared libraries etc.) Deines Programms vorhanden sind.

    Also genau wie bei Windows? Nichts mit "mein kompiliertes Programm läuft nur auf meinem Rechner mit meinem Kernel"? Dann müsste mein Programm ja problemlos überall laufen, wenn ich das so glauben darf.

    Wo finde ich eigentlich meine "shared libraries"? Und muss ich die dann nur zum Programm legen?

    0
  • N

    Stiefel2000 schrieb:

    Das war mir schon klar, aber scheinbar kann man es damit ja schaffen, Dateien zu erstellen, die auf diversen Linux-Systemen per einmaliger Ausführung ein Programm installieren. Sowas möchte ich haben, daher der Hinweis.

    Klar kann man. Aber man muss dann eben alles zu Fuß machen. Schreib Dir ein Shellscript, das Dein Programm nach /opt/deinprogramm kopiert und Symlinks auf die Binary nach /usr/bin legt bzw. Symlinks zur Manpage nach /usr/share/man oä. und Dein Programm ist installiert.

    Anstrengend daran ist für den User, dass Updates nicht automatisch vorgenommen werden können, es keine einheitliche Deinstallationsmöglichkeit gibt etc.

    Das klingt nach viel Aufwand, wenn ich nicht nur Ubuntu versorgen will, deshalb gefällt mir der Gedanke nicht. Aber die von dir verlinkte Anleitung schaue ich natürlich an, zuviel kann man ja nicht wissen.

    Naja, im wesentlichen brauchst Du eine RPM (Fedora, Centos, RHEL, SuSE, …) und eine DEB (Debian, Ubuntu, …), damit deckst Du praktisch den gesamten Markt ab, außer ein paar Exoten mit vergleichsweise geringem Marktanteil.

    nman schrieb:

    Also genau wie bei Windows? Nichts mit "mein kompiliertes Programm läuft nur auf meinem Rechner mit meinem Kernel"? Dann müsste mein Programm ja problemlos überall laufen, wenn ich das so glauben darf.

    Warum sollte Dein Programm nur auf Deinem Rechner und nur auf Deinem Kernel laufen? Wenn Du nicht irgendwas sehr komisches machst, stellst Du eine 32-Bit-Version und eine 64-Bit-Version zur Verfügung und Modulo Shared-Library-Probleme wars das dann auch schon wieder.

    Wo finde ich eigentlich meine "shared libraries"? Und muss ich die dann nur zum Programm legen?

    Naja, verwendest Du überhaupt irgendwelche externen Libraries? Wenn ja, welche?

    0
  • S

    Okay, wenn ich dich richtig verstehe, brauche ich also ein .deb- und ein .rpm-Paket.
    Ich hatte oben auch geschrieben, dass ich meinen Quellcode in diesen Paketen nicht zur Verfügung stellen möchte, die Arbeit am Programm ist mir dazu noch nicht weit genug fortgeschritten. Aber auf der verlinkten Seite (http://magazin.c-plusplus.net/artikel/Softwareinstallation%20f%FCr%20das%20Debian%20System) sieht es so aus, als sei der Quellcode im Paket enthalten. Ich konnte es leider noch nicht selbst ausprobieren, muss dazu noch ein paar Sachen vorbereiten.

    Wie kann ich übrigens ein rpm-Paket erstellen?

    0
  • ?

    Ich klinke mich mal kurz ein, weil ich das Thema auch spannend finde und auch nach fast 10 Jahren Linuxerfahrung bei diesen Sachen noch nicht richtig duchblicke.

    nman schrieb:

    Naja, im wesentlichen brauchst Du eine RPM (Fedora, Centos, RHEL, SuSE, …) und eine DEB (Debian, Ubuntu, …), damit deckst Du praktisch den gesamten Markt ab, außer ein paar Exoten mit vergleichsweise geringem Marktanteil.

    Ist es denn wirklich so, dass ein einmal erstelltes RPM bei *allen* RPM-basierten Distros läuft? Und ein DEB sowohl bei Ubuntu als auch Debian selbst? Weil, wenn das so wäre, müsste man doch auch die Repos theoretisch mixen können, oder nicht?

    Und wenn hier gesagt wird, dass bis auf Abhängigkeitsprobleme ein Binary grundsätzlich auf jedem Linuxsystem läuft, kann ich dann daraus folgern, dass es die Paketsysteme ausschließlich wegen dieser Abhängigkeitsprobleme und der konsistenten Updatemöglichkeit gibt? Also, dass es keinen weiteren speziellen technischen Grund dafür gibt?

    0
  • N

    dennis.cpp schrieb:

    Ich klinke mich mal kurz ein, weil ich das Thema auch spannend finde und auch nach fast 10 Jahren Linuxerfahrung bei diesen Sachen noch nicht richtig duchblicke.

    Ist auch kein ganz einfaches Thema, das man sofort versteht. Ich beantworte mal Deine Fragen so gut wie möglich und dann die von Stiefel2000.

    Ist es denn wirklich so, dass ein einmal erstelltes RPM bei *allen* RPM-basierten Distros läuft?

    Nein, nicht zwangsläufig. Wie gesagt kann es mit Shared Libraries – insbesondere mit deren Versionen – Probleme geben. Aber unter der Annahme eines einigermaßen simplen Programms (zB. nur Standard C++ mit libstdc++ oä. als Shared Library) brauchst Du normalerweise nur einmal kompilieren und das Programm läuft dann einfach überall.

    Wenn Du irgendwelche Libraries brauchst, wird es komplizierter. Entweder Du weißt, dass die auf allen unterstützten Distros in passenden Versionen verfügbar sind, oder Du musst sie statisch in Deine Binary reinlinken.

    Oder, wenn Du irgendwas besonders exotisches vorhast:
    http://www.stanford.edu/~pgbovine/cdepack.html

    Aber häufig bist Du nicht streng auf ganz bestimmte Library-Versionen angewiesen und nimmst einfach den kleinsten gemeinsamen Nenner, der überall verfügbar ist und alles funktioniert.

    Und ein DEB sowohl bei Ubuntu als auch Debian selbst?

    Ja, das funktioniert normalerweise bei selbstgebauten Sachen ohne enorme Dependencies sehr gut, weil sich Debian und Ubuntu so ähnlich sind.

    Weil, wenn das so wäre, müsste man doch auch die Repos theoretisch mixen können, oder nicht?

    Bis zu einem gewissen Grad kann man das ja auch. Ich verwende unter Debian PPAs für Ubuntu und unter CentOS diverse Fedora-Repos.

    Aufgrund von Versionsproblemen geht das natürlich nicht unbegrenzt. Daher gibt es auch Projekte wie EPEL und ELFF, die Fedora-Zeugs für RHEL/CentOS backporten oder backports.org (mittlerweile offiziell von Debian übernommen), das neuere Versionen von Debian-Paketen von Testing zu Stable zurückportiert etc.

    Und wenn hier gesagt wird, dass bis auf Abhängigkeitsprobleme ein Binary grundsätzlich auf jedem Linuxsystem läuft, kann ich dann daraus folgern, dass es die Paketsysteme ausschließlich wegen dieser Abhängigkeitsprobleme und der konsistenten Updatemöglichkeit gibt? Also, dass es keinen weiteren speziellen technischen Grund dafür gibt?

    Naja, bequeme Installation, bequeme Updates, bequeme Deinstallation, einheitliche Skripte, … Es gibt viele Gründe für Paketmanager. Natürlich wäre auch ein GNU/Linux komplett ohne Paketmanager möglich, sowie Du es zB. mit LFS hast. Nur ist das eben auf Dauer kaum benutzbar.

    0
  • N

    Stiefel2000 schrieb:

    Aber auf der verlinkten Seite (http://magazin.c-plusplus.net/artikel/Softwareinstallation%20f%FCr%20das%20Debian%20System) sieht es so aus, als sei der Quellcode im Paket enthalten.

    Nein, das missverstehst Du. Deine Skripte um die Pakete zu erstellen, packst Du zu den Sourcen dazu und Du hältst sie auch unter Versionskontrolle etc.

    Aber:

    $ ls -lh /var/cache/pbuilder/result 
insgesamt 35M 
-rw-r--r-- 1 christoph christoph 2,5K 2008-03-17 14:55 hallowelt_1.0.0-1.diff.gz 
-rw-r--r-- 1 christoph christoph  356 2008-03-17 14:55 hallowelt_1.0.0-1.dsc 
-rw-r--r-- 1 christoph christoph  732 2008-03-17 14:56 hallowelt_1.0.0-1_i386.changes 
-rw-r--r-- 1 christoph christoph 7,4K 2008-03-17 14:56 hallowelt_1.0.0-1_i386.deb 
-rw-r--r-- 1 christoph christoph 2,9K 2008-02-15 21:56 hallowelt_1.0.0.orig.tar.gz

    Die .deb ist ein reines Binärpaket. Die anderen Files haben alle in irgendeiner Form mit den Sourcen zu tun. Aber die musst Du selbstverständlich nicht verteilen.

    Wie kann ich übrigens ein rpm-Paket erstellen?

    Siehe http://fedoraproject.org/wiki/How_to_create_an_RPM_package oä.

    0
  • S

    Erstmal danke für die Hilfe. Ich habe gerade die Anleitung zum Erstellen von deb-Paketen von hier getestet, bin allerdings beim Bauen des Paketes gescheitert ("missing seperator" oder so in der rules-Datei). Ich werde es nochmal in Ruhe versuchen und melde mich dann.

    0
  • N

    Stiefel2000 schrieb:

    […]bin allerdings beim Bauen des Paketes gescheitert ("missing seperator" oder so in der rules-Datei). Ich werde es nochmal in Ruhe versuchen und melde mich dann.

    Ich habe jetzt gerade die Fehlermeldungen von GNU Make nicht im Kopf, aber das rules-File ist ein ganz normales Makefile. Dh. Du musst darauf achten, zum Einrücken richtige Tabs und keine Leerzeichen zu verwenden. Ist ein möglicher häufiger Copy & Paste-Fehler.

    0
  • P

    Wie wärs denn mit checkinstall - das bastelt auf Wunsch ein .deb oder .rpm
    - und wenn du dein Programm, so nicht zu umfangreich - statisch linkst ist
    das Bibliotheksproblem auch vom Tisch - und kann von den Anwendern
    auch wieder problemlos über die jeweilige Paketverwaltung entsorgt werden.

    0
  • ?

    , , , ,

    0
Anmelden zum Antworten