staging.inyokaproject.org

Ich möchte eigene Programme über ein ppa zur Verfügung stellen. Die größte Hürde ist dabei aber die Linux-Verzeichnisstruktur: So weit ich erkennen konnte, werden die Binaries nach /usr/bin gestopft. Aber wohin kommt der Rest des Programmes? Sprachdatein (die ganzen Strings für alle GUI-Sachen), die Hilfedatei, eventuell noch die Read-Me und ggf. andere? Gäbe es die Möglichkeit, alles in einem Ordner zu belassen, so dass Binary&Co. an einem Ort sind (nach /opt/programmname wäre zwar eine Möglichkeit, aber dafür ja nicht gedacht und daher zu vermeiden, oder)?

(Die Einstellungen als Inidatei in home/user/.programmname sind in der Fragestellung natürlich außen vor.)

Die grundlegende Antwort findest Du im Filesystem Hierarchy Standard, und dann letztlich in den offiziellen Dokumenten.

Außerdem empfiehlt es sich mal zu gucken, wie Andere das praktisch gemacht haben. Guck mal in den einschlägigen Dateilisten der Pakete, wohin die Leute ihr Zeug gepackt haben.

LG,

track

Danke erstmal, mein Problem scheint mir eher ein Verständnis- bzw. Definitionsproblem zu sein. Die Dokumentation habe ich gelesen, denke dabei aber: Hm, dieses Verzeichnis könnte passen, das andere aber auch. Fängt schon an bei Binaries: Passt in /usr/bin (unter Umständen auch /usr/sbin), /usr/ocal/bin und als "add-on application software packages" müsste meinem Verständnis nach sowieso alles Nicht-Distributions-mitgelieferte nach /opt.

Und sich anzugucken, wie andere (von mir gut gekannte Programme) das gelöst haben, steigert meine Verwirrung aber eher:

z.B Boinc: Arbeitsdaten des Users in /var/lib/boinc-client, einige Konfigdateien mit Symlinks nach /etc/boinc-client

Noch komplizierter als Boinc ist der Apache Webserver: Unter Windows ist der relativ rasch konfiguriert. Unter Linux bin ich auf der Suche nach den richtigen Konfigdateien irre geworden und auch verhungert.

Und Lazarus packt alles nach /usr/share/lazarus/1.6/ und linkt dann das Binary einfach nach /usr/bin/. Gefällt mir am besten, scheint mir aber auch das einzige Programm zu sein, dass es so macht.

Willst Du solch ein riesiges Programmpaket bauen, dass Du das ausgerechnet mit diesen beiden Programmen vergleichst ?? 😲

Wenn ich es mal eine Nummer kleiner fasse, finde ich z.B. bei evince (nur mal so, als beliebiges Beispiel) die Binaries in /usr/bin , diverse Libs in /usr/lib und den Rest irgendwo sinnfällig unter /usr/share . (± das selbe bei evolution)

Das wäre doch mal eine eher überschaubare Interpretation des FHS, oder ?

LG,

track

😀 Nein, ich hab's nur wegen halbwegs guter Kenntnis der Programme verglichen.

Deine Interpretation des FHS ist jedenfalls nachvollziehbar und hilft weiter, vielen Dank!

Zeig doch einfach mal her, was dein Programm alles an Dateien ablegt..

Thema ist zwar eigentlich schon erledigt, weil's ppa mit zumindest einem der Programme schon steht, aber um die letzte Frage zu beantworten:

Bei einem sind es bisher nur die Sprachdateien, also die ganzen Strings für die GUI mit der vom User gewählten Sprache und die ReadMe. Hilfedatei kommt vielleicht auch irgendwann noch. Das Programm ist Linux-only, sollte aber auch (ohne Neukompilierung) "portable" sein können, also dass es die Inidatei im selben Verzeichnis wie das Binary speichert, so dass man es mit sich herum tragen kann.

Bei einem anderen kommen noch Datenbank-Template (leere Datenbankdatei), sowie Texttemplates (leere RTF-Dateien) dazu. Die geänderten Templates (DB+RTF) werden dann dahin gespeichert, wo der User es will (Standardmäßig in /home/user/.appname/). Das Programm läuft auch auf Windows, sollte dazu noch "portable" sein können.

Bei Zweitgenanntem führt eigentlich kein Weg an der "Lazarus-Lösung" vorbei, wenn man sich das Geraffel der mehrfachen Implementierung von Pfaden für beide OS+portabel-Variante+Testcases sparen möchte. Und wenn man das dann bei einem so implementiert, ist man quasi gezwungen, das bei dem erstgenannten und wohlmöglich allem, was dann noch so kommt, auch so zu machen, weil: Man die Funktionen und Klassen für die Basisfunktionen (Einstellungen, Sprachunterstützung, et cetera) einfacher tauschen und wiederverwenden kann und man auch noch eine Sache weniger beachten muss, wenn man sich nach wohlmöglich tage- oder wochenlanger Pause dann für ein paar Stunden mal wieder mit diesem Programm beschäftigt.