bin-Verzeichnis wird bei dpkg -r gelöscht

[berni42]

Ich hab' gestern mal versucht mittels cmake ein Debian-Paket zu erstellen. Klappt auch alles, nur, wenn ich das Paket wieder lösche wird /usr/local/bin mit gelöscht (das ist ohne mein Paket leer und mein Paket installiert da eine Datei rein). Kann man das irgendwie durch geeignete Konfiguration des Pakets verhindern?

Und wenn ich dann das Paket neu installiere, wird /usr/local/bin wieder angelegt, aber mit anderen Rechten (keine Welt-Rechte, Sticky-Bit fehlt) und anderer Gruppe (root statt staff). Auch da die Frage: Kann man da was machen?

Code: Alles auswählen

# ls -lda bin
drwxrwsr-x 2 root staff 4096 Mär  7 17:32 bin
# dpkg -r croco
(Lese Datenbank ... 249797 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von croco (0.1.1) ...
dpkg: Warnung: Während Entfernens von croco ist Verzeichnis »/usr/local/share« nicht leer, wird daher nicht gelöscht
# ls -lda bin
ls: Zugriff auf 'bin' nicht möglich: Datei oder Verzeichnis nicht gefunden
# dpkg -i croco-0.1.1-Linux.deb 
Vormals nicht ausgewähltes Paket croco wird gewählt.
(Lese Datenbank ... 249768 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von croco-0.1.1-Linux.deb ...
Entpacken von croco (0.1.1) ...
croco (0.1.1) wird eingerichtet ...
# ls -lda bin
drwxrwx--- 2 root root 4096 Mär  7 17:34 bin

[smutbert]

Das ist nicht nur bei /usr/local/bin so sondern bei allen leeren Verzeichnissen so. Wenn das Verzeichnis im Paket vorkommt und bei der Deinstallation des Pakets abgesehen von den Dateien des Pakets selbst leer ist, dann wird es entfernt.

Der einfachste Weg das zu verhindern wäre eine (leere) Datei in dem Verzeichnis anzulegen. Also etwa

Code: Alles auswählen

# touch /usr/local/bin/do_not_delete

So etwas könnte man dann auch in das postinst-Skript des Pakets schreiben.

Allerdings ist /usr/local ja eher für von der Paketverwaltung nicht erfasste Software gedacht - ein selbstgemachtes Paket könntest du ja getrost nach /usr/bin installieren lassen oder wenn du es vom Rest des Systems trennen willst, dann in eine eigene Verzeichnisstruktur in /opt installieren und eventuelle binaries in einem bin-Verzeichnis verlinken - wenn du den Link im postinst-Skript erstellst und im postrm-Skript wieder entfernst, bliebe auch ein ansonsten leeres /usr/local/bin unbehelligt.

[berni42]

Allerdings ist /usr/local ja eher für von der Paketverwaltung nicht erfasste Software gedacht

Ah, guter Hinweis. Das hab' ich wohl falsch verstanden. Ich dachte /usr/bin ist für offizielle Pakete, und /usr/local für welche, die man selber gebastelt hat. Dann ändere ich das mal. Das behebt dann wohl auch das Lösch-Problem, weil man ja schon irgendwie davon ausgehen kann, dass /usr/bin irgendwas enthält.

Aber da fällt mir noch was ein: Im bin-Verzeichnis ist eigentlich nur ein kleines Skript, dass eine PHP-Datei aufruft. Die PHP-Dateien habe ich nach /share/<eigenes Verzeichnis>/ gepackt. In einem Unterverzeichnis davon sind dann noch ELF-executables, die vom PHP-Frontend aufgerufen werden und eigentlich nicht für einen eigenständigen Aufruf gedacht sind, also das bin-Verzeichnis nur vollmüllen würden. Ist das so OK? Oder sollte ich mir da eine bessere Struktur einfallen lassen?

[smutbert]

Ich finde es in Ordnung, aber ganz richtig ist es glaube ich nicht, weil /usr/share für architekturunabhängige Dateien gedacht ist, also wieder eher nicht für elf-Programme. So wie ich die Sache auslege, wären die Binaries also in /usr/lib/<Paket/Programmname>/... besser aufgehoben.

Aber es wäre besser du glaubst mir nicht einfach alles sondern bildest dir selbst eine Meinung - ich weiß bestenfalls überblicksartig bescheid:
https://wiki.debian.org/FilesystemHierarchyStandard
https://en.wikipedia.org/wiki/Filesyste ... y_Standard
https://jankarres.de/2014/02/debian-ver ... -erklaert/
https://wiki.ubuntuusers.de/Verzeichnisstruktur/
…

[berni42]

Aber es wäre besser du glaubst mir nicht einfach alles sondern bildest dir selbst eine Meinung

Das ist ja eben der Punkt: Ich hab' mir die Standards schon durchgesehen und weiß nicht genau, wie ich das in meinem Fall interpretieren soll. Die Idee, die Binaries nach lib zu schieben hatte ich auch zuerst; aber eigentlich sind es ja keine Libraries. Das mit dem "architektur-unabhängig" ist aber ein Punkt, der mir so nicht aufgefallen ist. Ich hatte "shared" eher als "Alles, was sonst nirgends passt" aufgefasst.

[smutbert]

shared ist ja sozusagen alles in /usr (bis auf local) und zwar shared zwischen verschiedenen Computern, auch wenn man das kaum noch nutzt. Bei /usr/shared kommt halt zusätzlich das Kriterium der Architekturunabhängigkeit dazu.

In /usr/lib/... finden sich jedenfalls viele Programme von Paketen, u.a. /usr/lib/xorg/Xorg (der X-Server) und jede Menge Programme, die systemd verwendet in /usr/lib/systemd - so ganz falsch kann das also nicht sein.


Du brauchst dir aber auch den Kopf nicht zu sehr zu zerbrechen, Pakete von Drittherstellern verstoßen oft böse gegen die Gepflogenheiten, so hat mir zB das Debianpaket eines Druckertreiber unter /usr einen Cache der verfügbaren Netzwerkdrucker geschrieben, etwas was ganz eindeutig nach /var/... gehört hätte. Als ich die Prüfsummen der installierten Dateien überprüft habe, hat mir das im ersten Augenblick einen Heidenschreck eingejagt, weil offensichtlich jemand oder etwas Dateien unter /usr/lib/... manipuliert hatte.
Solange du also solche Schnitzer unterlässt, geht es hier imho höchstens um Schönheitsfehler.

[berni42]

Du brauchst dir aber auch den Kopf nicht zu sehr zu zerbrechen, Pakete von Drittherstellern verstoßen oft böse gegen die Gepflogenheiten, [...]
Solange du also solche Schnitzer unterlässt, geht es hier imho höchstens um Schönheitsfehler.

Ich möcht's halt richtig machen. Hab' die Binaries jetzt mal nach lib verschoben. Und inzwischen auch lintian entdeckt. Das hatte mir das mit den Binaries in shared auch angemeckert... Jetzt bin ich dabei Dependencies einzugeben. Ich denke, die benötigten Pakete habe ich inzwischen weitgehend identifiziert, aber mir ist unklar, wie man rausfinden will, welche Versionsnummern man von den Libs braucht. Hab' jetzt erst mal gar keine angegeben. Depends scheint mir die hohe Kunst des Paketierens zu sein, oder?

[hikaru]

Das ist nicht nur bei /usr/local/bin so sondern bei allen leeren Verzeichnissen so. Wenn das Verzeichnis im Paket vorkommt und bei der Deinstallation des Pakets abgesehen von den Dateien des Pakets selbst leer ist, dann wird es entfernt.

Der einfachste Weg das zu verhindern wäre eine (leere) Datei in dem Verzeichnis anzulegen. Also etwa

Code: Alles auswählen

# touch /usr/local/bin/do_not_delete

So etwas könnte man dann auch in das postinst-Skript des Pakets schreiben.

Das klingt wackelig. Wenn du zwei Pakete hast die so vorgehen, dann treten sie sich gegenseitig auf die Füße, weil nicht klar ist, welches Paket für /usr/local/bin/do_not_delete zuständig ist.

Ich kenne mich mit cmake nicht aus und weiß auch nicht ob das relevant ist, aber wenn ich es richtig verstanden habe, dann war das Problem, dass das Paket überhaupt /usr/local/bin enthält. In dem Fall wird natürlich das Verzeichnis bei der Deinstallation des Pakets auch wieder gelöscht.
Ich denke es wäre schlauer, das Verzeichnis selbst gar nicht im Paket zu haben, sondern nur dessen Inhalte. Falls man sich nicht sicher ist, ob das Verzeichnis überhaupt existiert, dann könnte man es ja zur Sicherheit mit einem preinst-Script anlegen.

[smutbert]

Ja, ist wackelig, aber bei mehreren Paketen, die Dateien in einem bestimmten Verzeichnis beinhalten, läuft man ohnehin nicht Gefahr, dass das Verzeichnis entfernt wird. War aber eh nur als Notlösung gedacht und Berni42 hat es inzwischen richtig gelöst.

Dein zweiter Absatz ist mir aber nicht ganz klar: Wie kann man in einem Archiv Dateien haben und gleichzeitig nicht das Verzeichnis, in dem die sich befinden?

[hikaru]

Dein zweiter Absatz ist mir aber nicht ganz klar: Wie kann man in einem Archiv Dateien haben und gleichzeitig nicht das Verzeichnis, in dem die sich befinden?

Das geht natürlich nicht (ohne hässliche Trickserei). Da hatte ich vorhin zu schnell geschossen.

[KBDCALLS]

Mit dh-make läßt sich doch ein OriginalSource in ein Debiansource verwandeln. Das so entstande Debianverzeichnis edtiert man so wie benötigt . Im Normalfalle reicht schon das was von dh_make generiert wird. Alternativ könnte man auch die schon fertigen Debiansourcen als Vorlage nehmen, falls es nur um eine neuere Programmversion geht.

• https://www.debian.org/doc/manuals/main ... ex.de.html