|
2010-03-12
Anmeldungsdatum:
12. März 2010
Beiträge: 27
|
Hallo ! Ich schraube seit einiger Zeit an einer Software für eine Dia-Show, weil mir das was ich so im Software Center finde nicht wirklich gefällt. Als IDE verwende ich Anjuta. Das klappt alles recht gut, im großen und ganzen ist die Software fertig, es ist ein nettes kleines Programm. Nun möchte ich es als freie Software auch Dritten zur Verfügung stellen, z.B. als Download von meiner Homepage. Und hier beginnen meine Probleme, denn ich habe noch nie Ubuntu-Software für den Gebrauch außerhalb meines eigenen Rechners erstellt. Folgende Dateien gehören zu meinem kleinen Projekt:
Es sind 2 Fragen die ich mir stelle und bei denen ich für jeden Tipp wirklich dankbar wäre.
Die erste Frage ist: In welcher Art und Weise sollte das Programm zur Verfügung gestellt werden ?
Nach meiner bisherigen Recherche denke ich dass ein .deb Paket schön wäre, aber die Schwelle ist hoch da ich noch nie ein Paket erstellt habe. Alternativ wäre ein Tarball mit den notwendigen Sourcen ein Möglichkeit. Im Augenblick tendiere ich trotz der Aufwands eher zum Paket. Liege ich damit richtig ? Was ist den so „das übliche“ in der Ubuntu-Welt ?
Die zweite Frage ist: Wohin sollte installiert werden, wie ist die Verzeichnisstruktur ?
Ich habe mir den WIKi-Artikel durchgelesen: http://wiki.ubuntuusers.de/Verzeichnisstruktur, aber ich muss zugeben dass ich nun eher verwirrt als aufgeklärt bin. Scheinbar gibt es 3 Kandidaten für den/die Zielordner:
/opt sollte eingesetzt werden, wenn die Installation „an der Paketverwaltung vorbei“ installiert werden sollte. Wenn ich nun ein .deb Paket anbiete, dass manuell zu installieren ist, heißt das dann ich arbeite „an der Paketverwaltung vorbei“ ? Ist das also mein Installationsziel ? Und wo lege ich dann den Starter, dass UI-File und die PNGs ab ? oder /usr/bin für die binaries, bzw. /usr/share/applications für den Starter, und wohin müssten dann die zugehörigen PNGs und das UI File ? oder /usr/local – hier heißt es auch dass es für Software gedacht ist die man an der Paketverwaltung vorbei installiert hat. Es stellen sich die gleichen Fragen wie bei /opt. Sorry für die lange Anfrage. Aber wie Ihr seht bin ich völlig verwirrt. Ich komme halt nicht aus der Ubuntu-Welt sondern kümmere mich hauptberuflich um Software für SAP ERP. Da ist die Installation (Transport) von Software für den Entwickler erheblich einfacher … Liebe Grüße,
Martin
|
|
Antiqua
Anmeldungsdatum:
30. Dezember 2008
Beiträge: 4532
|
Ich zäum das Pferd mal von hinten auf. Ich persönlich bevorzuge Fremd-Software, die sich unter /usr/local installiert. Fremd-Software ist für mich alles, was nicht über die Paketverwaltung aus den originalen Repositorien kommt. Egal ob jetzt aus den Sourcen oder schon als fertiges Paket ins Dateisystem "gepfuscht". /opt wird eigentlich nur von größeren Geschichten benutzt. VirtualBox, Chrome, Java, zusätzliches selbstgebautes Qt, ... und hat den Nachteil, das es nicht im $PATH ist. Du müsstest also entweder auch für Links in Verzeichnisse, die im $PATH sind, sorgen, oder jedenfalls das irgendwie handeln.
Zum Debian-Paketbau: ja, ist nicht so einfach, wenn richtig gemacht.
Eigene Pakete anzubieten hat auch den Nachteil, dass du ggf. mehrere Pakete bauen musst. Jeweils zwei (32- u. 64-Bit) für 12.04, 13.10, ggf. schon 14.04, Debian Stable, ... und was ist dann mit den rpm-Distires, SuSE, RedHat und den Gentoos, Archs und Slackwares? Egal wie du dich entscheidest, die Sourcen auch anzubieten schadet jedenfalls nicht.
|
|
diesch
Anmeldungsdatum:
18. Februar 2009
Beiträge: 5072
|
2010-03-12 schrieb: Die erste Frage ist: In welcher Art und Weise sollte das Programm zur Verfügung gestellt werden ?
Minimum ist ein Tarball mit dem Quellcode. Sinnvoll ist es, den Quellcode öffentlich zugänglich in einer Versionsverwaltung zu pflegen, z.B. auf http://www.launchpad.net. Damit hast du auch gleich ein Backup ☺ Fertige Pakete für z.B. Ubuntu sind für die Anwender praktisch. Für Ubuntu ist es sinnvoll, die Pakete zusätzlich über ein PPA anzubieten.
Die zweite Frage ist: Wohin sollte installiert werden, wie ist die Verzeichnisstruktur ?
Laut Anjuta unterstützt Anjuta autogen. Benutze die dafür definierten Variablen (die sind bestimmt in der Doku zu Anjuta irgendwo beschrieben).
Glade-Dateien, Bilder usw. kommen nach $(datadir)/PROGRAMMNAME/ oder einen Unterordner davon. Damit wird dann auch das Paket-Bauen relativ einfach. Schau dir am besten auch mal ein paar Pakete an, du bekommst die Quellen mit
|
|
barcc
Anmeldungsdatum:
13. Juli 2007
Beiträge: 696
|
2010-03-12 schrieb: Nach meiner bisherigen Recherche denke ich dass ein .deb Paket schön wäre, aber die Schwelle ist hoch da ich noch nie ein Paket erstellt habe. Alternativ wäre ein Tarball mit den notwendigen Sourcen ein Möglichkeit. Im Augenblick tendiere ich trotz der Aufwands eher zum Paket. Liege ich damit richtig ? Was ist den so „das übliche“ in der Ubuntu-Welt ?
Wenn dein Programm freie Software sein soll, musst du auch den Quellcode bereitstellen. Ein Tarball ist üblich, es kommt aber auch immer häufiger vor, dass die Entwickler einfach einen Link auf ein öffentliches VCS-Repository angeben (z.B. Launchpad oder GitHub). Bei Programmen, die sich an Normalbenutzer richtet, ist es mMn vorteilhaft, zusätzlich auch deb-Pakete anzubieten. Anstatt das Paket als Download auf deiner Homepage anzubieten, solltest du lieber ein PPA anlegen, das hat ein paar Vorteile.
/opt sollte eingesetzt werden, wenn die Installation „an der Paketverwaltung vorbei“ installiert werden sollte.
/opt kann man verwenden, wenn man sich nicht an die Verzeichnisstruktur halten kann oder will, dort installiert Ubuntu beispielsweise kommerzielle Spiele. Wenn ich nun ein .deb Paket anbiete, dass manuell zu installieren ist, heißt das dann ich arbeite „an der Paketverwaltung vorbei“ ?
Nein /usr/bin für die binaries, bzw. /usr/share/applications für den Starter, …
Ja … und wohin müssten dann die zugehörigen PNGs und das UI File ?
Nach /usr/share/PAKETNAME/ /usr/local – hier heißt es auch dass es für Software gedacht ist die man an der Paketverwaltung vorbei installiert hat. Es stellen sich die gleichen Fragen wie bei /opt.
Guter Ton ist es, wenn make install nach /usr/local installiert, Pakete sollten dieses Verzeichnis niemals verwenden.
Sorry für die lange Anfrage. Aber wie Ihr seht bin ich völlig verwirrt. Ich komme halt nicht aus der Ubuntu-Welt sondern kümmere mich hauptberuflich um Software für SAP ERP. Da ist die Installation (Transport) von Software für den Entwickler erheblich einfacher …
Wenn du ein Standard-Build-System wie z.B. autotools oder cmake benutzt, muss du dich möglicherweise um die Installationsorte gar nicht kümmern, weil das automatisch alles richtig gemacht wird.
Liebe Grüße,
Martin
|
|
Antiqua
Anmeldungsdatum:
30. Dezember 2008
Beiträge: 4532
|
barcc schrieb:
Guter Ton ist es, wenn make install nach /usr/local installiert, Pakete sollten dieses Verzeichnis niemals verwenden.
Das mit make install unterschreib ich, aber wo ist der Unterschied zwischen selbst compiliert und selbst compiliert und dann gepackt in ein Deb. Ist dein Deb z.B. ein Ersatz/Fork eines anderen Paketes, es also z.B. Binarys oder allgemeiner, Files mitbringt, deren Name auch in Paketen aus dem Repo vorkommen und im selben Ort abgelegt werden, gibts bei /usr/local keine Probleme, es werden die Binarys aus /usr/local gestartet, weil im $PATH vorher und die Paketverwaltung überschreibt nix, sollte ein Update des im Repo befindlichen Paketes kommen, das das gleichnamige Binary unter /usr ablegt. Da man nur schwer abschätzen kann, ob im riesigen original Repo nicht doch dieser Konflikt auftreten kann, ist es immer sicherer, alles, was nicht im original Repo liegt, nicht nach /usr (oder /bin oder /sbin) zu legen. Und da bietet sich eben /usr/local an.
|
|
diesch
Anmeldungsdatum:
18. Februar 2009
Beiträge: 5072
|
Wenn zwei Pakete die gleiche Datei benutzen wollen, meckert die Paketverwaltung, und ich kann das mir dpkg-divert beheben, da wird also zumindest nichts überschrieben. Unter /usr/local/ will ich am der Paketverwaltung vorbei Software installieren. /usr/local/ kann z.B. auch aus dem Netz kommen und ist dann möglicherweise nicht beschreibbar. Daher soll die Paketverwaltung sich da raushalten. Soweit ich mich erinnere, entspricht das auch den Regel von Debian und Ubuntu.
|
|
barcc
Anmeldungsdatum:
13. Juli 2007
Beiträge: 696
|
Alles was unter /usr/local/ liegt sollte man löschen können ohne mit der Paketverwaltung in Konflikt zu kommen. Wenn man beispielsweise ein Programm manuell installiert, dann ein deb-Paket baut und installiert, sollten sich beide nicht ins Gehege kommen. Dann kann man beide parallel testen und unabhängig deinstallieren. Und wenn du so ein Paket weitergibst, machst du dann nicht die manuelle Installation auf anderen Systemen kaputt. Da man nur schwer abschätzen kann, ob im riesigen original Repo nicht doch dieser Konflikt auftreten kann, ist es immer sicherer, alles, was nicht im original Repo liegt, nicht nach /usr (oder /bin oder /sbin) zu legen. Und da bietet sich eben /usr/local an.
Hundertprozentig kannst du Konflikte nie ausschließen (weder in /usr noch in /usr/local). Wenn man aber den Paketnamen und die Namen der Binarys sorgfältig wählt (google, apt-file), sollte man dann gut schlafen können. Ist dein Deb z.B. ein Ersatz/Fork eines anderen Paketes, …
Wenn man nicht sicherstellen kann, dass beide Pakete sich nicht überschneiden, kann man einen Konflikt deklarieren, so dass beide Pakete nicht gleichzeitig installierbar sind. Edit:
diesch schrieb: … Soweit ich mich erinnere, entspricht das auch den Regel von Debian und Ubuntu.
Debian Policy 9.1.2
|
|
2010-03-12
(Themenstarter)
Anmeldungsdatum:
12. März 2010
Beiträge: 27
|
Danke ! Das hat mir richtig geholfen. Ich habe verstanden:
/usr/local/... eher für Dinge die via Make lokal auf dem System erstellt wurden /usr/... eher falls man die Paketverwaltung benutzt, auch wenn es "handgemachte" Pakete sind /opt nur für Installationen die ganz weit weg vom Standard sind
Ich denke ich werde ein Paket bauen (Danke für den PPA-Tipp), damit ein einfacher Zugang für die Programminstallation da ist, und darüber hinaus die Sourcen mit einem kurzen Readme als Tarball. Drückt mir die Daumen. Eine Frage hätte ich noch: Wie gesagt benutze ich Anjuta, das wiederum nutzt Autogen. Gibt es eine Möglichkeit, die verwendeten Pfade im C Coding zu ermitteln ? Denn ich muss zum Start meines Programms einige Datendateien lesen (PNGs) und habe ein Problem damit, denn ich kenne den Installationspfad nicht. Zwar gibt es in der GLIB einige Funktionen die in die Richtung gehen, z.B. g_get_user_config_dir (), aber so richtig passt das alles nicht. Ich bin mir sicher es gibt einen üblichen Mechanismus um das Problem zu lösen - nur welchen ? Beste Grüße,
Martin
|
|
diesch
Anmeldungsdatum:
18. Februar 2009
Beiträge: 5072
|
2010-03-12 schrieb: Ich bin mir sicher es gibt einen üblichen Mechanismus um das Problem zu lösen - nur welchen ?
Entweder du setzt passende Compiler-Flags, oder du erzeugst die eine Header-Datei, siehe
https://www.gnu.org/software/autoconf/manual/autoconf.html#Defining-Directories
|
|
2010-03-12
(Themenstarter)
Anmeldungsdatum:
12. März 2010
Beiträge: 27
|
Danke für den Tipp - an der Stelle hatte ich noch nicht gesucht. Ich kreuze dann mal die Finger und starte den Paketbau ... das kann ja noch heiter werden. Aber ich bin optimistisch. Danke nochmal an alle !
|