Programm unter Linux optimal in Dateisystem einfügen

[fred.reichbier]

Hallo,

gleich vorweg, ich bin noch nicht allzu lang bei Linux
Ich habe folgenden Sachverhalt:
Ein Hauptskript, ein Konfigurations-GUI-Skript, und ein Skript, das von beiden anderen Skripten importiert wird. Dazu noch einen locale/-Ordner mit den gettext-Dateien. Nun meine Frage: Wie kann ich dieses Programm so in den Linux (speziell Ubuntu-)Verzeichnisbaum einfügen, also wohin kommen die beiden Haupt-Skripte, kommt das importierte Skript in die site-packages, wohin die gettext-Sachen...

Die Frage hat nur am Rande mit Python zu tun, trotzdem stelle ich sie hier mal, falls das nicht erwünscht sein sollte, lasst es mich wissen

Gruß,

Fred

[CM]

Hoi

Die Frage hat nur am Rande mit Python zu tun, trotzdem stelle ich sie hier mal, falls das nicht erwünscht sein sollte, lasst es mich wissen

Ach, Quatsch, warum nicht?

Also, ich kann natürlich nur sagen, wie ich es mache und nicht, wie Du oder andere es machen sollen:
Skripte kopiere ich sicher nicht in site-packages. Das ist Paketen und Modulen vorbehalten (auch die eigenen), die ggf. von Skripten importiert werden. Damit Skripte überall von der Shell ausführbar sind, kopiere ich sie in /home/username/bin und füge das Verzeichnis zu PATH (in .bashrc:

Code: Alles auswählen

export PATH="${PATH}:/home/username/bin"

. Das Verzeichnis gibt es nicht per default, aber man kann es ja kreieren oder sich ein anderes aussuchen*. Wenn Du Deine Skripte in anderen Verzeichnissen organisierst, helfen aliases und symlinks.
Was ist ein GUI-Skript ? Meine GUIs sind jedenfalls per symlink im selben Verzeichnis zu finden oder direkt unter dem Applikationspanel eingeordnet. (Rechter Mausklick auf das Applikationspanel und die Einträge editieren.)

HTH
Christian

* Der Grund warum ich es so mache, ist, daß ich auf verschieden System mit unterschiedlichen Verzeichnisbäumen unterwegs bin, da kann ich das so einfach inkl. der Unterverzeichnisse kopieren.

[fred.reichbier]

Hallo,

danke erstmal für die Antwort, aber ich glaube, meine Frage war etwas komisch formuliert, ich meinte nämlich etwas anderes

Meine Frage ist, wie ich ein Python-Skript als Programm 'ubuntutypisch' in den Verzeichnisbaum einfügen kann, so, wie andere Programme (z.B. Exaile, das ist ja auch in Python geschrieben). 'Richtige' Linux-Programme liegen ja nicht im Home-Verzeichnis des Users, sondern eben irgendwo in den /usr-Verzeichnissen. Endziel wäre dann eben, ein deb-Paket für das Programm zu erzeugen.

Habe mir jetzt gerade mal Exaile angesehen, das legt einen Symlink auf sich selbst in /usr/bin ab, irgendeine komische .so in /usr/lib/exaile, und die Daten in /usr/share/exaile. Sollte man das genauso machen?

Trotzdem danke für die Antwort

Gruß Fred

[CM]

Ach so, hatte ich Dich quasi "unterinterpretiert". Aber natürlich, warum solltest Du Dich nicht an die Gepflogenheiten (z. B. http://www.ubuntugeek.com/linux-or-ubun ... cture.html - hat jemand eine bessere Übersicht?) halten?

Gruß,
Christian

[veers]

http://www.pathname.com/fhs/
http://www.debian.org/doc/packaging-man ... on-policy/
http://www.debian.org/doc/debian-policy/
Sowie allgemein:
http://www.debian.org/devel/

Viel Spass beim lesen *g*

[lunar]

Um das ganze detailliert auszuführen:

Es gibt für jede Installation ein sog. Prefix. Bei einer Nutzerinstallation ist das in der Regel das Homeverzeichnis, bei einem Distributionspaket /usr und bei 3rd Party Programmen entweder /opt/foo oder /usr/local.

Unterhalb dieses Prefixes gibt es dann verschiedene Verzeichnisse für bestimmte Dateien:

• /bin für ausführbare Dateien
• /sbin für ausführbare Dateien, die dem Admin vorbehalten sind (bei normalen Programmen eher nicht der Fall
• /share für architektur-unabhängige Dateien:
  • /share/foo für irgendwelche Datendateien (wie z.B. xml GUIs)
  • /share/locale für die Gettext Hierarchie
• /lib für architektur-abhängige Dateien.
  • /lib/python2.5/site-packages für globale Python-Module
  • /lib/foo für Anwendungsspezifische Python-Module sowie andere architekturabhängige Dateien

Diese Richtlinien gibt der FHS vor. Allerdings ist dieser im Bezug auf Python meistens nicht korrekt umgesetzt. Streng genommen müssten Python-Module unter /usr liegen, da sie architektur-unabhängig sind. Allerdings installieren sämtliche Distributionen sowie die Distutils Python-Module unterhalb der /lib Hierarchie.

Allerdings würde ich nicht unbedingt empfehlen, diese Hierarchie für Python-Programme strikt einzuhalten. Bei binär compilierten Programmen wird das Prefix normalerweise einkompiliert, so dass das Auffinden der entsprechenden Dateien kein Problem ist. Bei Python jedoch gibt es kein Kompilieren, das Prefix muss also entweder zur Laufzeit bestimmt werden, oder mindestens eine Datei muss während der Installation angepasst werden. Ersteres ist relativ schwer, letzteres sehr hässlich.

Deswegen würde ich empfehlen, die package_data Option der Distutils zu nutzen und die Anwendung sauber in ein Paket zu verpacken. Dann kann man nämlich alle relevanten Daten sauber zur Laufzeit über das __file__ Attribut ansprechen. So mache ich das in meinen Projekten, und so wird das auch von anderen Anwendungen und Bibliotheken wie z.B. Django gemacht. Zudem erspart diese Vorgehensweise krude Installationshacks, da sie komplett per Distutils umsetzbar ist. Das erleichtert auch Distributoren das Verpacken deiner Anwendung, da für Distutils meistens Standardtools für die Paketierung existieren (bei Debian gibt es dh_python, außerdem unterstützt cdbs die distutils, für gentoo gitb es die distutils eclass, wodurch sich das Paketscript auf geschätzte 10 Zeilen reduziert).

[fred.reichbier]

Hallo,

vielen Dank für eure Antworten, bin jetzt etwas schlauer

Ich habe jetzt mal probeweise alle Dateien (auch Grafiken) in /usr/share/programm gelegt und einen symlink in /usr/bin auf die Haupdatei gelegt. Die locale-Sachen habe ich dann in /usr/share/locale eingefügt. Das alles funktioniert auch. Um das Ganze jetzt in die distutils zu bekommen, werde ich dann data_files verwenden, um alles in /usr/share zu verpacken. Ist das richtig so, oder sollte ich das anders machen?

Danke nochmal,
Fred