Debian Paketmanagement-Tool APT ist in Version 2.9 erschienen. In Vorbereitung auf v3.0 bringt eine neue UI etwas Farbe und mehr Übersicht ins Spiel.

Quelle

Der Paketmanager Apt von Debian und vielen anderen Distributionen kann ab sofort mit Snapshots umgehen. Die wiederum muss jedoch das Repository unterstützten.

Unter „snapshot.debian.org“ verwahrt das Debian-Projekt sämtliche alte Pakete, penibel sortiert nach Datum. Auf diese Weise kann man zum einen nachvollziehen, welche Pakete am 01.02.2023 aktuell waren und bei Bedarf auch diese Pakete einspielen.

Den Umgang mit solchen Snapshots vereinfacht das neue APT 2.7: Über den Parameter „–snapshot“ greift der Paketmanager gezielt auf die Pakete an einem vorgegebenen Datum zurück. Auf diese Weise kann man etwa den Editor „nano“ hinzuholen, wie er am 01.02.2023 ausgeliefert wurde.

Die Datumsangabe erfolgt allerdings mit einem kryptischen Zeitstempel der Form:

„–snapshot 20230201T153118Z“. In diesem Beispiel würde APT auf den Stand vom 01.02.2023 zugreifen. Prinzipiell ist das Snapshot-System nicht auf „snapshot.debian.org“ begrenzt. Der Server, der das Repository offeriert, muss allerdings diese Form der Snapshots unterstützen.

Die APT-Entwickler weisen darauf hin, dass sich die Unterstützung von Snapshots in den nächsten APT-Versionen noch ändern könnte.

Der Beitrag APT 2.7 erlaubt bequemen Zugriff auf Snapshots erschien zuerst auf Linux-Magazin.

Der Paketmanager von Debian und vielen anderen Distr

Der Beitrag Neue APT-Version erlaubt bequemen Zugriff auf Snapshots erschien zuerst auf LinuxCommunity.

Nach einer längeren Entscheidungsphase hat sich das Debian-Projekt dafür ausgesprochen, Closed-Source-Firmware in die offizielle Distribution aufzunehmen.

Die Abstimmung über das Thema war nötig geworden, nachdem es für viele Geräte inzwischen Freie Treiber gibt, die Firmware aber weiterhin Closed-Source ist und entsprechende Abhängigkeiten mitbringen. Die Firmware-Updates sind unter anderem auch für Security-Fixes nötig.

Es standen diverse Vorschläge zum Thema zur Abstimmung, von der kompletten Ablehnung bis zur Zustimmung. Entschieden haben sich die Debian-Mitglieder für die Option 5, die den  Debian Social Contract in Punkt 5 um den Satz erweitert: „Die offiziellen Debian-Medien können Firmware enthalten, die sonst nicht Teil des Debian-Systems ist, um die Verwendung von Debian mit Hardware zu ermöglichen, die solche Firmware benötigt.“

Der Vorschlag besagt, dass künftig nicht-freie Firmware-Pakete aus dem “non-free-firmware”-Abschnitt des Debian-Archivs in offiziellen Medien (Installer-Images und Live-Images) aufgenommen werden. Die so enthaltenen Firmware-Binärdateien werden dann standardmäßig aktiviert, wenn das System feststellt, dass sie benötigt werden, aber wenn möglich, sollen Möglichkeiten für die Benutzer vorgesehen sein, dies beim Booten zu deaktivieren, etwa via Boot-Menü-Option, Kernel-Befehlszeile oder ähnliches.

Wenn das Installations-/Live-System läuft, sollen dem Benutzer Informationen darüber zur Verfügung gestellt werden, welche Firmware geladen wurde (sowohl freie als auch unfreie), und diese Informationen sollen auch auf dem Zielsystem gespeichert sein, damit User sie später finden können, heißt es im gewählten Vorschlag. Sollte sich herausstellen, dass unfreie Firmware notwendig sei, werde das Zielsystem auch so konfiguriert, dass die unfreie Firmware-Komponente standardmäßig in der Datei apt sources.list verwendet werde. Die Benutzer sollten so Sicherheitsaktualisierungen und wichtige Korrekturen für Firmware-Binärdateien wie jede andere installierte Software erhalten.

Das Debian-Projekt hat nun einige Aufgabe vor sich, um diese Änderungen umzusetzen. Wie der frühere Projektleiter Steve McIntyre schreibt, sollte die Arbeit noch idealerweise vor dem Freeze für Debian 12 (Bookworm), das im Januar 2023 erscheinen soll, abgeschlossen sein.

Der Beitrag Debian ermöglicht Closed-Source-Firmware erschien zuerst auf Linux-Magazin.

Beim Ausführen von Skripten auf einer Linux Konsole, die apt install beinhalten, taucht folgende Meldung auf: 

WARNING : apt does not have a stable CLI interface. Use with caution in scripts.

Doch warum wird eine Warnung angezeigt? Die Lösung ist relativ simpel.

Vor Jahren hatte ich mal eine Übersicht von apt vs. apt-get veröffentlicht. Ich habe sie euch unten noch einmal eingebunden.
Im Artikel ist zu lesen, dass apt unter anderem einen grafischen Fortschrittsbalken ausgibt.

Genau das ist einer der Gründe, warum das Kommandozeilentool bei der Verwendung in Scripten ein WARNING meldet. Denn diese Fortschritts-Ausgabe kann von Scripten fehlerhaft interpretiert werden und ist im Prinzip nur für Endnutzer gemacht, aber nicht wirklich für Skripte. Darum sollte hier eher auf apt-get zurückgegriffen werden.

Gleiches gilt übrigens auch für apt show programm-name. Hier sollte besser apt-cache show programm-name verwendet werden.

Repositories aus dritter Hand sind umstritten. Wer sie dennoch will, findet in dem Tool deb-get ein Helferlein, das Installation und Schlüsselablage automatisch erledigt.

Quelle