Veröffentlicht am

IMHO: Was fehlt: silent updates

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Seit einigen Versionen beherrscht PackageKit in Kombination mit Gnome so genannte „Offline-Updates“, was nichts anderes bedeutet, als das Updates während des Bootvorgangs in einer speziellen Umgebung installiert werden.

Wenn man diesen Gedanken jedoch konsequent zu ende denkt, können die Offline-Updates nur der erste Schritt auf dem Weg zu stillen Updates, die man auch etwas vulgär „halt die Klappe und mach einfach Modus“ nennen könnte, gewesen sein. Dieser zweite Schritt ist jedoch eigentlich schon mehr als überfällig.

Oder um es mit den Worten von David Sieg zu sagen:

… Jetzt mal ehrlich: Wen interessiert, dass libcurl, libfoo und libArsch aktualisiert wurden?

Das sind doch wieder Informationen, die nur Arch-, Gentoo- und andere Wirrköpfe brauchen…

Die meisten Benutzer dürfte es in der Tat kaum interessieren, welche Pakete gerade aktualisiert werden sollen. Sie wollen einfach ein stabiles und sicheres System, mit dem sie arbeiten können und nicht mit für sie belanglosen Informationen, wie eben der, welche Updates verfügbar sind, belästigt werden.

Microsoft hat das erkannt und bietet diese stillen Updates, bei dem die Updates im Hintergrund heruntergeladen und beim nächsten Herunterfahren des Systems installiert werden, schon seit einiger Zeit an. Warum tut sich Linux dann bitte so schwer damit seinen Nutzern so etwas anzubieten?

Oder ist Linux im Grunde noch immer ein System von Freaks für Freaks?

Veröffentlicht am

IMHO: Testet Eure Updates, bevor ihr sie veröffentlicht!

Es ist heute zum zweiten mal binnen weniger Tage passiert, das ein kaputtes Update in updates-testing gelandet ist. Bei ersten mal hat es LibreOffice erwischt, das aufgrund von nicht bzw. nicht ordentlich kommunizierten Änderungen am harfbuzz-Paket nicht mehr benutzbar war.

Heute dann das accountsservice Update, welches permanente SELinux-Fehlermeldungen verursacht und dadurch das System extrem ausbremst, da SELinux quasi am durchdrehen ist.

Ja, mir ist bekannt, das Updates in updates-testing fehlerhaft sein können und ja, ich weiß auch, das sich Fedora 19 offiziell noch in der Entwicklung befindet. Aber wenn ich mir das Problem mit dem accountsservice Paket anschaue, dann beschleicht mich der Verdacht, das da jemand das Update entweder gar nicht oder nicht vernünftig getestet hat, bevor er es nach updates-testing hochgeladen hat. Ich unterstelle einfach mal, dass das Problem mit SELinux aufgefallen wäre, wenn das Update vorher lokal vernünftig getestet worden wäre.

Vernünftiges Testen heißt in diesem Fall für mich, dass das Update z.B. in einer virtuellen Maschine mit Fedora 19 installiert wird und das vor der Installation des Updates erst einmal ein Update des Systems gemacht wird und das SELinux bei dem System im enforcing Modus läuft.

Das Systeme durch ein Update, auch wenn es „nur“ in updates-testing liegt, nahezu unbenutzbar werden, kann und darf in meinen Augen nicht passieren! Und ich denke, diesen Anspruch darf man als Anwender durchaus stellen, auch und gerade weil Fedora eine so genannte bleeding-edge Distribution ist.

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).
Veröffentlicht am

yum-security Plugin für umfangreiche Updates zweckentfremden

Wer des öfteren Bugs beim Fedora Projekt meldet, kennt das Problem, das auftritt, wenn der entsprechende Bugreport mit einem Paketupdate geschlossen wird. Unter Umständen kann es dabei vorkommen, das in der Mitteilung Update-Kommandos genannt werden, die (wie z.B. bei KDE-Komponenten) sehr viele Pakete enthalten und dementsprechend lang sind.

Da solche langen Update-Kommandos extrem unhandlich sind und sich in der Regel auch schlecht per Copy&Paste ausführen lassen, hat Kevin Kofler heute auf der Entwickler-Liste folgenden Trick vorgeschlagen:

Das Yum-Plugin yum-security bietet einen Parameter –advisory, der sich für auch für solche Zwecke wie diesen zweckentfremden lässt. Dafür muss, falls nicht bereits geschehen, zuerst das Security-Plugin mittels

su -c'yum install yum-security'

installiert werden.

Anschließend kann man das oben als Beispiel genannte Update auch mit folgendem Kommando durchführen:

su -c'yum – enablerepo=updates-testing – advisory=FEDORA-2012-14137 update'

Wobei man FEDORA-2012-14137 durch die in der Benachrichtigung genannte Advisory-Nummer ersetzen muss.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

Veröffentlicht am

Kommt grubby auf das Abstellgleis?

Ben Roser hat auf der Entwickler-Mailingliste vorgeschlagen, bei der Installation von Kernel-Paketen grubby durch grub2-mkconfig zu ersetzen.

Er begründet seinen Vorschlag damit, das grub2-mkconfig nur einen Eintrag für Fedora erstellt und sämtliche installierten Kernel in einem Untermenü verbirgt, was seiner Ansicht nach deutlich übersichtlicher ist. Grubby hingegen fügt alle installierten Kernel direkt ins Hauptmenü ein, was auf Dauer und vor allem bei Multiboot-Systemen zu Lasten der Übersichtlichkeit geht.

Dem momentanen Verlauf der Diskussion nach zu urteilen, stehen die Chancen für eine Umsetzung des Vorschlags nicht schlecht, da die übrigen Teilnehmer der Diskussion mit der momentanen Situation ebenfalls nicht zufrieden sind. So merkt Andre Robatino in seinem Beitrag zu der Diskussion beispielsweise an, das er momentan dazu tendiert, grub2-mkconfig nach jedem Kernel-Update manuell auszuführen, um das Grub-Menü übersichtlich zu halten.