lohnt sich ein eigenes Debian-Paket?

[Bauform B. (bauformb)]

hallo!

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...

https://manpages.debian.org/testing/e2fsprogs/e2fsck.conf.5.en.html#broken_system_clock

[Dergute W. (derguteweka)]

Moin,

Bauform B. schrieb:
> 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?

scnr,
WK

[Martin H. (horo)]

Bauform B. schrieb:
> ... alles in ein .deb zu packen. Aber was wäre der Vorteil?

Du kannst alles wieder rückstandsfrei entfernen.

[MaWin O. (mawin_original)]

Bauform B. schrieb:
> 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.

[Ein T. (ein_typ)]

Bauform B. schrieb:
> 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.

HTH && HF! ;-)

[Norbert (der_norbert)]

Bauform B. schrieb:
> Aber was wäre der Vorteil?

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.

Edit: Abhängigkeiten können verwaltet werden

[Bauform B. (bauformb)]

Dergute W. schrieb:
> 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 T. schrieb:
> 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.


Martin H. schrieb:
> Du kannst alles wieder rückstandsfrei entfernen.

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.

[MaWin O. (mawin_original)]

Na dann nutze es halt nicht, wenn du nicht willst.
Ich sehe das Problem nicht.

Du gehst ja schon mit Abneigung an die Sache heran. Was glaubst du denn, 
was dann dabei herauskommen wird?

[Bauform B. (bauformb)]

MaWin O. schrieb:
> Du gehst ja schon mit Abneigung an die Sache heran.

Garnicht wahr, seit bookworm bin ich wieder begeistert von Debian

apt install sysvinit-core
reboot
apt purge systemd*
genießen ;)

> Was glaubst du denn, was dann dabei herauskommen wird?

Etwas funktionierendes, mit oder ohne Paket. Die Frage ist nur, was 
übersichtlicher wird.

[MaWin O. (mawin_original)]

Bauform B. schrieb:
> apt purge systemd*

Genau was ich meinte.

> Die Frage ist nur, was übersichtlicher wird.

Ich glaube die Frage ist eher, was besser in deine Ideologie passt.

[Mathias A. (mrdelphi)]

Bauform B. schrieb:
> 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.

[Bauform B. (bauformb)]

Mathias A. schrieb:
> Nach Debian-Policy ist es natürlich nicht erlaubt

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.


MaWin O. schrieb:
> Bauform B. schrieb:
>> apt purge systemd*
> Genau was ich meinte.

schön, dass wir uns einig sind :)

[MaWin O. (mawin_original)]

Bauform B. schrieb:
> Genau das möchte ich vermeiden.

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.

[C-hater (c-hater)]

Martin H. schrieb:
> Bauform B. schrieb:
>> ... 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.

[MaWin O. (mawin_original)]

C-hater schrieb:
> dies mit den
> "*.d"-Konfig-Verzeichnissen in Griff zu bekommen. Leider aber doch mehr
> oder weniger erfolglos.

So ein Quatsch. Das .d-Konzept ist mittlerweile sehr weit gekommen und 
wird mittlerweile bei praktisch allem relevanten verwendet.

[Bauform B. (bauformb)]

C-hater schrieb:
> 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.

MaWin O. schrieb:
> Das .d-Konzept ist mittlerweile sehr weit gekommen und
> wird mittlerweile bei praktisch allem relevanten verwendet.

Naja, der Trend geht ja dahin, dass fsck nicht mehr relevant ist. Und 
Wünsche des Benutzers sind ja sowieso nicht relevant.

[Norbert (der_norbert)]

Bauform B. schrieb:
> 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.

[Norbert (der_norbert)]

Bauform B. schrieb:
> 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?
Doch selbst da braucht man es gelegentlich. Und verschwinden wird's auch 
nicht.

[Bauform B. (bauformb)]

Norbert schrieb:
> /etc/grub.d/* zum Konfigurieren. (mit README)

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.

Norbert schrieb:
> Bauform B. schrieb:
>> 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

Maximum mount count:  -1
Check interval:        0 (<none>)
----
https://e2fsprogs.sourceforge.net/e2fsprogs-release.html

E2fsprogs 1.05 (September 7, 1996)
    By default, create filesystems where the default checkinterval is
    6 months (180 days). Linux servers can be robust enough that
    20 reboots can be a long, long time.
E2fsprogs 1.36 (February 5, 2005)
    Fix e2fsck so that a checkinterval of zero disables
    a time-based check of the filesystem.
E2fsprogs 1.41.10 (February 10, 2010)
    Add new e2fsck.conf configuration option, default/broken_system_clock
    to support systems with broken CMOS hardware clocks. Also, since too
    many distributions seem to have broken virtualization scripts now,
    e2fsck will by default accept dates which are off by up to 24 hours
    by default. (Addresses Debian Bugs: #559776, #557636)
E2fsprogs 1.42 (November 29, 2011)
    If the enable_periodic_fsck option is false in /etc/mke2fs.conf (which
    is the default), mke2fs will now set the s_max_mnt_count superblock
    field to -1, instead of 0. Kernels older then 3.0 will print a spurious
    message on each mount then they see a s_max_mnt_count set to 0, which
    will annoy users. (Addresses Debian Bug: #632637)
E2fsprogs 1.44.2 (May 14, 2018)
  Fixes
    E2fsck now prints a warning message if broken_system_clock is set
    in e2fsck.conf and this causes the check interval to be ignored
    so it is clear to the user.
E2fsprogs 1.46.2 (February 28, 2021)
  UI and Features
    Teach the tune2fs program to support "random" as an argument to the
    -c option, which sets the maximum mount count.
    (Addresses Debian Bug: #926293)
----
Ubuntus Steve Langasek ist sicher, dass sich niemand für fsck interessiert:
  https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/513644

[MaWin O. (mawin_original)]

Bauform B. schrieb:
> Naja, der Trend geht ja dahin, dass fsck nicht mehr relevant ist. Und
> Wünsche des Benutzers sind ja sowieso nicht relevant.

Ich habe seit 20 Jahren kein fsck mehr ausgeführt.
Ich würde sagen, der Trend ist recht fortgeschritten.

Bauform B. schrieb:
> 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?

Habe noch nie Probleme mit automatisch überschriebenen commandlines 
gehabt. Welches Paket (außer Grub selbst) soll das machen?

Ganz im Gegenteil. Seit es grub.d gibt funktioniert ein Grub-Paketupdate 
ohne manuelles frickeln. Ein Traum.

[Gustl B. (gustl_b)]

MaWin O. schrieb:
> Ich habe seit 20 Jahren kein fsck mehr ausgeführt.
> Ich würde sagen, der Trend ist recht fortgeschritten.

Braucht man bei zfs auch nicht. Aber ein scrub gegen Bitrot sollte man 
ab und an mal laufen lassen.

[MaWin O. (mawin_original)]

Gustl B. schrieb:
> 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.

[Gustl B. (gustl_b)]

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?