für ein eigenes Programm auf dem eigenen Rechner reicht ein Makefile. Wenn es mehrere Programme werden, die zusammen gehören, gibt es für jedes ein Makefile und eins, mit dem man alles auf einmal bauen kann. Der nächste Schritt wäre, alles in ein .deb zu packen. Aber was wäre der Vorteil? Selbst wenn ich das auf mehreren Rechnern installieren will, funktioniert ein .tgz doch genauso gut?
Einen Vorteil hätte es: ich muss meine Programme nicht aus /etc/rc.local.d/ starten, sondern könnte ein echtes initscript benutzen und das früher starten, im Extremfall sogar als allererstes überhaupt. Geht das auch ohne komplettes Debian-Paket?
Die konkrete Anwendung: ich würde es direkt nach hwclock.sh einhängen und meine eigene GPS-RTC benutzen. Dann wäre es völlig egal, was hwclock (vorher oder beim Runterfahren) anstellt und wie falsch oder garnicht die PC-RTC geht.
Damit könnte fsck schon mit der richtigen Uhrzeit laufen. Rein für e2fsck gibt es als Alternative die Option "broken_system_clock". Das ginge auch ohne eigenes Paket...
Einen Vorteil hätte es: ich muss meine Programme nicht aus
/etc/rc.local.d/ starten, sondern könnte ein echtes initscript benutzen
und das früher starten, im Extremfall sogar als allererstes überhaupt.
Geht das auch ohne komplettes Debian-Paket?
Mal ganz crazy ueberlegt:
Bei LinuxFromScratch ist kein einziges Debian-Paket beteiligt. Im ganzen System nicht.Sonst waer's ja nicht mehr "from Scratch". Trotzdem schaffen's diese Teufelskerle irgendwie init-scripte ans Laufen zu bringen, oder gar mit systemd zu arbeiten. Zauberei?
Einen Vorteil hätte es: ich muss meine Programme nicht aus
/etc/rc.local.d/ starten, sondern könnte ein echtes initscript benutzen
und das früher starten, im Extremfall sogar als allererstes überhaupt.
Mit Systemd musst du dich nicht mit diesen Vorkriegstechnologien herumärgern.
für ein eigenes Programm auf dem eigenen Rechner reicht ein Makefile.
Wenn es mehrere Programme werden, die zusammen gehören, gibt es für
jedes ein Makefile und eins, mit dem man alles auf einmal bauen kann.
Der nächste Schritt wäre, alles in ein .deb zu packen. Aber was wäre der
Vorteil? Selbst wenn ich das auf mehreren Rechnern installieren will,
funktioniert ein .tgz doch genauso gut?
Ein Tarball bietet aber keine Pre- und Postinstallationsskripte, kein automatisches Management von Abhängigkeiten, keine Nachvollziehbarkeit in der Paketdatenbank, welches Paket welche Datei an welchen Ort installiert hat, keine Markierung von Konfigurationsdateien, und so weiter, und so fort. So ein "richtiges" Paket bietet viele Vorzüge gegenüber deutlich weniger eleganten Möglichkeiten wie Makefiles und Tarballs.
Wenn es wirklich für Debian und / oder Ubuntu sein soll, würde ich aber anstelle von klassischen SysV-Initskripten eher systemd-Units empfehlen, sowie -- solange Deine Software nicht Bestandteil der Distribution wird -- eine Installation in /opt/ gemäß dem Filesystem Hierarchy Standard (FHS) und der Linux Standard Base (LSB). Richtig schön wäre es natürlich, ein Source-Paket zu erstellen und am Ende womöglich auch ein Paketrepo, wenn man häufiger eigene Pakete installieren oder aktualisieren möchte.
dpkg --get-selections zeigt deine Pakete an.
apt install|reinstall|remove funktioniert.
In aptitude werden die Pakete in der Sektion: ›Veraltete und selbst erstellte Pakete‹ angezeigt.
dpkg -i paket.deb weiß von sich aus wo alles hin muss.
Bei LinuxFromScratch ist kein einziges Debian-Paket beteiligt. Im ganzen
System nicht.Sonst waer's ja nicht mehr "from Scratch". Trotzdem
schaffen's diese Teufelskerle irgendwie init-scripte ans Laufen zu
bringen
Was heißt "irgendwie"? Ein gut abgehangenes /sbin/init benutzen, eine inittab und ein rcS-Script eintippen und fertig. Das kann ja jeder. Wenn keine Distribution mit ihren Regeln mitmischt, ist alles viel einfacher. Andererseits, eine Zillion fertig kompilierte libraries sind auch nicht zu verachten.
Ein Tarball bietet aber keine Pre- und Postinstallationsskripte, kein
automatisches Management von Abhängigkeiten
Was darf ein Pre-inst-Script denn recht viel mehr, als Dateien in z.B. /etc/cron.daily/ zu installieren? Darf es legalerweise /etc/e2fsck.conf neu erstellen oder die kernel cmdline ändern? Der Admin darf das und kann das, aber ein Script?
Automatische Abhängigkeiten sind natürlich nett: Conflicts: systemd ;)
solange Deine Software nicht Bestandteil der Distribution wird
wird sie sicher nicht
eine Installation in opt gemäß dem Filesystem Hierarchy Standard
(FHS) und der Linux Standard Base (LSB).
Zunächst wächst das Ganze natürlich unter /home/user/ und fertige binaries wären in /usr/local/bin und /usr/local/sbin gut aufgehoben. Irgendwie finde ich /opt schon zu "offiziell". Unter opt vermisse ich auch ein sbin, oder gehört ein daemon auch nach bin? Ansonsten passt /opt natürlich, vor allem, weil ein Paket wohl nichts nach /usr/local installieren darf.
Das ist überhaupt nicht vorgesehen. Updates natürlich schon.
Inzwischen habe ich die Frage etwas komprimiert: Was wird einfacher, .deb oder .tgz, falls mal jemand diese Programme reparieren will? Immerhin ist so ein Paket rein lokal und ohne repo irgendwie fremdartig.
Einen Vorteil hätte es: ich muss meine Programme nicht aus
/etc/rc.local.d/ starten, sondern könnte ein echtes initscript benutzen
und das früher starten, im Extremfall sogar als allererstes überhaupt.
Geht das auch ohne komplettes Debian-Paket?
Ja, das geht, man kann einfach das initscript unter /etc/rc.d/ erstellen und die entsprechenden Symlinks für Start/Stop.
Nach Debian-Policy ist es natürlich nicht erlaubt, aber es löscht die Files nicht weg, man sollte nur Namen wählen die nicht allzu generisch sind und möglicherweise mit Debian-Paketen kollidieren könnten. Z.B. "my-...", oder den eigenen Namen einbauen, o.ä.
Würde es aber nur empfehlen wenn es auf max einer Handvoll Rechner installiert werden soll und sich nur selten oder nie ändert; anderenfalls wäre dann ein .deb schon sehr hilfreich um den Überblick zu behalten wo es nun installiert ist und wo nicht, und in welcher Version.
Genau das möchte ich vermeiden. Früher haben mich diese Regeln überhaupt nicht interessiert, so etwa: erlaubt ist, was der kernel versteht. Jetzt muss ich noch viel lernen.
anderenfalls wäre dann ein .deb schon sehr hilfreich um den Überblick zu
behalten wo es nun installiert ist und wo nicht, und in welcher Version.
Keine Frage, und es muss für den Benutzer offensichtlich sein.
Dann lies doch die Debian Maintainer-Doku.
Wenn du dich an diese Regeln halten wirst, wirst du da nicht drum herumkommen.
Das kann dir hier niemand abnehmen.
... alles in ein .deb zu packen. Aber was wäre der Vorteil?
Du kannst alles wieder rückstandsfrei entfernen.
Vorsicht: Das ist zwar tatsächlich so, aber hat auch Macken! Nämlich: im Laufe der Installation überschriebene oder gemergte Konfigurationen werden NICHT auf den ursprünglichen Stand zurück gesetzt.
Zwar bemüht man sich seit undenklichen Zeiten, dies mit den "*.d"-Konfig-Verzeichnissen in Griff zu bekommen. Leider aber doch mehr oder weniger erfolglos. Das Konzept wurde einfach nicht bis zu letzten Konsequenz durchdacht und ist darüber hinaus noch nichtmal über alle Pakete konsequent durchgesetzt.
Ein Trauerspiel. Kein Problem natürlich für Leute, die sich auskennen, aber u.U. der absolute Showstopper für Laien.
Zwar bemüht man sich seit undenklichen Zeiten, dies mit den
"*.d"-Konfig-Verzeichnissen in Griff zu bekommen. Leider aber doch mehr
oder weniger erfolglos. Das Konzept wurde einfach nicht bis zu letzten
Konsequenz durchdacht und ist darüber hinaus noch nichtmal über alle
Pakete konsequent durchgesetzt.
Es ist aber auch knifflig. Ich würde z.B. die kernel cmdline anpassen. Dafür scheint /etc/default/grub zuständig zu sein. Es gibt aber auch /etc/default/grub.d/. Files, die man da rein packt, überschreiben die Einträge in default/grub ohne Warnung. Wem gehört jetzt was? Man könnte meinen, die cmdline gehört dem Admin und einzelne Pakete haben die nicht anzufassen. Dafür sprechen die Kommentare in default/grub. Aber warum gibt es dann grub.d? /etc/default/ ist wohl Debian-spezifisch, also hilft "info grub" nicht weiter und "man grub" gibt es nicht.
Oder: e2fsck liest /etc/e2fsck.conf, falls vorhanden, installiert es aber nicht. Ein anderes (mein) Paket darf die Datei aber nicht neu erstellen, das darf nur der Admin. Was wohl auch vernünftig ist. Aber ich mein, ob der Admin jetzt an einer oder an 7 Stellen Hand anlegen muss, ist doch egal. Ein Debian-Paket würde sich erst dann wirklich lohnen, wenn es nur installiert werden muss.
Es ist aber auch knifflig. Ich würde z.B. die kernel cmdline anpassen.
Dafür scheint /etc/default/grub zuständig zu sein. Es gibt aber auch
/etc/default/grub.d/. Files, die man da rein packt, überschreiben die
Einträge in default/grub ohne Warnung. Wem gehört jetzt was? Man könnte
meinen, die cmdline gehört dem Admin und einzelne Pakete haben die nicht
anzufassen. Dafür sprechen die Kommentare in default/grub. Aber warum
gibt es dann grub.d? /etc/default/ ist wohl Debian-spezifisch, also
hilft "info grub" nicht weiter und "man grub" gibt es nicht.
/etc/grub.d/* zum Konfigurieren. (mit README)
update-grub um die grub.cfg automatisch zu generieren.
Ja, um das Boot-Menü zu erweitern "and then adjust the default setting via /etc/default/grub". Nach dem README brauche ich also auch /etc/default/grub und /etc/default/grub.d/ bleibt rätselhaft.
Naja, der Trend geht ja dahin, dass fsck nicht mehr relevant ist.
Hab ich noch nie gehört. Oder beziehst du dich auf Journal-FS?
Trend, mehr nicht. Auf der Suche nach Stolpersteinen für ein read-only / haben mich diese Einstellungen bei meinen ext4-Partitionen verwundert. Daraufhin habe ich ein paar Hinweise gefunden
Aber ein scrub gegen Bitrot sollte man
ab und an mal laufen lassen.
Gibt es da auch tatsächliche Gründe für? "Sollte man" ist keine hinreichende technische Begründung.
Ich habe mit keinem meiner verwendeten FSe bisher irgendwelche Probleme gehabt, die mich zu einem fsck-Lauf veranlasst hätten. Das sind ReiserFS, ext3, ext4 und btrfs, in chronologischer Nutzungsreihenfolge.
Gute Frage.
Bitrot gab oder gibt es wirklich und zwar wenn Daten lange liegen ohne neu geschrieben zu werden.
Wie groß das Problem ist weiß ich nicht und auch nicht was lange bedeutet.
Jedenfalls kann zfs einzelne Bitkipper korrigieren. Beim scrub wird alles gelesen überprüft, bei Bedarf korrigiert und neu geschrieben. In den letzten grob 5 Jahren die ich zfs verwende hatte ich vielleicht eine Hand (keine zwei Hände) voll korrigierte Bits bei meinen monatlichen scrubs. Bei einem 16T raidz. Kommt also echt selten vor und würde vielleicht auch nicht auffallen.
Wie ist das eigentlich mit Dateien, müssen die immer vollständig korrekt sein mit Checksumme damit die funktionieren?
Was passiert bei einem Bild, Video, Word wenn man ein Bit flippt?
