(gelöst) bindeb-pkg

[KP97]

...Was weiß ich, was in dem Zusammenhang „Threads“ sind?

Wenn Dein Prozessor 4 Kerne hat, dann heißt es -j4,
wenn das automatisch ermittelt werden soll, heißt es -j`nproc`, wenn Du den Prozessor nicht voll ausnutzen willst, kann der Parameter entfallen.
Hast Du meine Lösung mal ausprobiert? Ist zumindest zum Kompilieren einfacher zu merken als ein ellenlanges Kommando.

[guennid]

Hast Du meine Lösung mal ausprobiert?

Hatte ich vor, aber jetzt nicht mehr. Denn der output unterscheidet sich ja nicht. Aber wenn mein privates Kennzeichen=LOCALVERSION später automatisch im vmlinuz erscheint, so wie bei towo, und insbesondere im Modulverzeichnis unter /lib/modules, dann halte ich das für eine starke Verbesserung gegenüber unseren „outputs“.

Grüße, Günther

und danke für die Erläuterungen zu den „Threads“!

aber noch mal zu towos apt clean und apt distclean:

Mit apt clean leert man doch /var/cache/apt/archives. Und das soll jetzt das Quellverzeichns der Kern-Komilation „bereinigen“? apt-distclean habe ich noch nie benutzt.

[Livingston]

aber noch mal zu towos apt clean und apt distclean:

towo hat make, nicht apt geschrieben. Damit räumst du die Sourcen auf.

[guennid]

[guennid]

Zu JTH
Ich verstehe „Paketnamen“ offenbar (und womöglich fälschlicherweiuse) bisher anders als du. Aber darüber muss ich noch nachdenken. Den Unterschied zwischen _ und - habe ich nicht beachtet. Bei dem was bindeb-pkg erzeugt, ist also das, was ich bisher als Version (und lokale Version) verstanden habe, erst mal Bestandteil des NAMENS, also linux-image-4.19.75-x61.0_... Über das weitere muss ich noch nachdenken.
Warum ich - gäbe es das Paket namens linux-image - nur ein einziges installieren könnte ist mir noch unklar.
Ein Paket namens linux-image gibt es nicht, das habe ich nachvollzogen. Es gibt Pakete namens linux-image-amd64 linux-image-686, etc.

[towo]

Es gibt Pakete namens linux-image-amd64 linux-image-686,

Die enthalten aber keinen Kernel. Das sind nur Metapakete und referenzieren die eigentlichen Image-Pakete per Versionsnummer.

[guennid]

Soweit war's mir schon klar, aber es sind gültige Paketnamen im Gegensatz zu „linux-image“. Ich bin am Nachdenken darüber, warum von bindeb-pkg erzeugte Paketnamen, die ich als Monstrum bezeichnet habe, möglichweise notwendig und damit sinnvoll sind.

Grüße, Günther

[towo]

Code: Alles auswählen

~/test
towo:OMPC-AV3> dget linux-image-amd64
dget: retrieving http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_5.3.9-1_amd64.deb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   354  100   354    0     0    986      0 --:--:-- --:--:-- --:--:--   986
100  1432  100  1432    0     0   3369      0 --:--:-- --:--:-- --:--:--  604k

~/test
towo:OMPC-AV3> la -al
insgesamt 44
drwxr-xr-x   3 towo towo  4096 Nov 14 10:26 .
drwxr-xr-x 165 towo towo 20480 Nov 12 07:01 ..
-rw-r--r--   1 towo towo  1432 Nov 14 10:26 linux-image-amd64_5.3.9-1_amd64.deb

Fällt Dir was auf?
Ich halte die Diskussion über die Paketnamen für relativ sinnfrei.

[guennid]

Fällt Dir was auf?

Nein. Ich verfüge nicht über deine Kenntnisse.

Ich halte die Diskussion über die Paketnamen für relativ sinnfrei.

Unter der Voraussetzung, dass wir beide unter „relativ“ das gleiche verstehen, könnte ich mir vorstellen, deiner Meinung zu sein. Und ich meine auch, sowas Ähnliches sagte ich bereits, das mit dem „relativ sinnfrei“.

Grüße, Günther

[JTH]

Warum ich - gäbe es das Paket namens linux-image - nur ein einziges installieren könnte ist mir noch unklar.

Nochmal als Denkanstoß:

Wenn du etwas installierst, machst du das normalerweise etwa so:

Code: Alles auswählen

# apt install bash

Dabei interessiert dich meist nicht, welche Version des Pakets/Programms installiert wird, auch wenn man sie ausdrücklich mit angeben könnte. Es gibt für viele Pakete ein Debian-stable-Release über sowieso nur eine Version; die Backports hier mal ignoriert. Der Paketname ist hier „bash“.

Wenn ich jetzt aber ein

Code: Alles auswählen

# apt full-upgrade

ausführe, wird zwangsweise die neueste im Repository verfügbare Version von bash installiert; apt-pinning etc. hier auch mal ignoriert. Das Update von z.B. Bash 3.0 auf Bash 4.0 könnte jetzt Änderungen mitbringen, mit denen z.B. manche Boot-Skripte nicht mehr funktionieren. Die Paketversion wäre hier 3.0 bzw. 4.0.

Um zu verhindern, dass mein System nach einem Update kaputt ist, muss ich also die alte Version sicherheitshalber behalten. Das geht aber nicht, wenn das Paket nur bash heißt, das kann nur in genau einer Version installiert sein. Man hängt stattdessen die Version an den Namen an, z.B. bash-3.0 und bash-4.0. Die kann ich jetzt nebeneinander installieren:

Code: Alles auswählen

# apt install bash-3.0 bash-4.0

Damit ich aber trotzdem automatisch bei einem apt full-upgrade die neueste Version bekomme, gibt es ein Metapaket. Das Metapaket hängt dann nur von einem anderen Paket ab und ist selbst quasi leer. Es könnte z.B. ein Paket bash-meta geben, das von bash-3.0 abhängt.

Wenn bash-meta bei einem apt full-upgrade jetzt neuerdings von bash-4.0 abhängt, bekomme ich letzteres automatisch installiert – behalte aber bash-3.0. Die Paketversion von bash-meta wäre hier vor dem Update 3.0 und nach dem Update 4.0. (Der Behalten-Part braucht evtl. entsprechende apt-Konfiguration, das hier auch mal ignoriert. Für den Kernel hat apt diese Konfiguration von Haus aus mit dabei.)

Wenn du oben die Bash durch den Kernel ersetzt, hast du z.B. ein Problem, wenn nach einem Update ein Treiber nicht mehr so funktioniert wie vorher. Man möchte deshalb bei einem Update die alte Version des Kernels immer erstmal behalten.

Die Dateinamen der Pakete oben wären:

Code: Alles auswählen

# Ohne Metapaket:
bash_3.0_amd64.deb
bash_4.0_amd64.deb

# Mit Metapaket:
bash-meta_3.0_amd64.deb
bash-meta_4.0_amd64.deb
bash-3.0_3.0_amd64.deb
bash-4.0_4.0_amd64.deb

Ich war ja versucht, hier systemd statt bash als Beispiel zu nehmen

Das die Architektur in den Namen oben auch nochmal redundant auftaucht, ist vermutlich Multiarch und anderem geschuldet.

Ich halt mich mal ans „vermutlich“. Als „notwendig“ einzusehen vermag ich's nicht, denn dass

Ein Paket sich im Dateinamen im Repository halt nur mit Name, Version & Architektur eindeutig benennen (lässt)

, ist ja in meinem letzten Beispiel (ohne Redundanz) berücksichtigt.

Da noch als Ergänzung: Ja, auch das amd64 in linux-image-amd64 ist notwendig, sonst gäbe es Probleme bei Multiarch.

Ups, der Text wurde länger als geplant

[guennid]

Ich war ja versucht, hier systemd statt bash als Beispiel zu nehmen

Was ist systemd?

Danke für deine Mühe!!! Ich denke, ich sehe jetzt klarer.

Grüße, Günther