Bisher hat sich Fedora 22 als die unbequemste Fedorainstallation erwiesen. Schuld an der ganzen Sache ist in erster Linie das neue dnf.
Wir haben rund um yum eine komplette Infrastruktur gebildet, so dass wir die an uns gestellten Anforderungen gezielt erfüllen können. Das neue dnf ist leider nicht in der Lage, zahlreiche dieser Anforderungen zu bedienen. Meiner Ansicht nach, haben sich die Entwickler und um dnf maßlos übernommen bzw. ist dessen Einführung absolut verfrüht.
Es steht zwar weiterhin das yum als Ersatz zur Verfügung. Allerdings kommt der Auswurf "yum is deprecated" sicherlich nicht gut bei einer Produktvorstellung an.
Hier zahlreiche Fehlermeldungen rund um dnf:
#1: dnf ist nicht in der Lage, vernünftig im chroot Umgebungen zu arbeiten. Statt RPM Schlüssel zu übernehmen, bricht dnf einfach nur ab. Wenn man die Querverlinkungen durchliest, stellt sich sogar heraus, dass dnf nicht in der Lage war, nfs Nutzer anzulegen, gerade weil es abgestürzt ist (das gesamte Paket fehlte).
#2: Unsere Anforderungen beötigen ein Äquivalent zu yumdb, um Attribute in der yumdb (Respektive dnfdb), setzen, löschen bzw. modifizieren zu können. Diese Funktionalität ist vollkommen nicht existent.
#3: Verbose/Debug Ausgabe nicht bestimmt genug. Unsere Anforderungen benötigen eine Liste der heruntergeladenen Pakete. Mit yum -d 3 konnte man diese Liste per Ausgabe grep'en und weiterverarbeiten. Das neue dnf hat sich dieser Thematik vollständig entledigt. Ein vollständiger use case ist in folgenden Beschreibungen zu finden.
#4: Diesmal keine dnf Anforderung, sondern eine Anforderung an Virtualisierung. Zum Thema System Integration sind wir angehalten, virtuelle Maschinen zu nutzen. Das Installieren mittels Anaconda benötigt 3.5 Stunden auf normalen corporate Notebooks mit GIS Images. Die Verzögerung ist durch einen Fehler im GTK+ (Spinner) begründet. Statt das Flag für Anaconda auf "false" zu setzen (welches einen drastischen Performanzgewinn mit sich bringen würde), schiebt man sich per Argumentation nur gegenseitig die Schuld zu (naja nicht ganz).
#5: Gnome-Shell kommt mit Netzwerkkarten nicht klar. Sobald man am Notebook mehr als ein WLAN betreibt (das Interne bzw. auch noch ein Externes), kommt Gnome-Shell nicht mehr klar. Die Netzwerke behindern sich gegenseitig. Will man eines von beiden abschalten, so schaltet sich das gesamte WLAN ab, schaltet man eines der Geräte wieder ein, schaltet sich das gesamte WLAN (und alle anderen Geräte wieder ein).
Bisher kann ich nicht behaupten, dass mir Fedora 22 wirklich Spaß macht. Einige Fehler lassen sich durch Modifikationen umgehen. Am schlimmsten für uns ist die Tatsache das "dnf" leider nicht nutzbar ist.
#6: Soeben einen Drucker installiert. Leider lässt sich unter Gnome-Shell (und dessen Setup Tool) die Seite nicht von Letter auf A4 umstellen. Immer wieder springt die Auswahl auf Letter zurück. Durchaus geglückt. Ob ich hierfür noch einen Bugzilla Ticket aufmache. Ich habe echt keine Lust mehr dazu, da ich das System nutzen und nicht erstmal Alpha-Tester spielen möchte.
#7: Erststart von Gnome-Shell auf einem i3 Notebook x > 5 Minuten. Vermutlich Packagekit, Tracker und anderes Cache Gedöns.
#8: Abermals ein dnf Problem. dnf gibt gegenüber yum andere Rückgabewerte an die console zurück, so dass Scripte und Systeme, die rund um yum (dnf) geschrieben wurden, sich nun vollkommen anders verhalten. Laut Aussage sei dies so geplant. Nur führt es zu nichts, wenn sich 3rd party Anwendungen nun vollkommen falsch verhalten.
#9: dnf builddep verhält sich vollkommen anders als yum-builddep. Es findet nicht Ansatzweise die vollständigen Abhängigkeiten. Wir rennen hier mit unseren Systemen von einem in den nächsten Fehler.
Wir ecken bereits an der Frustrationsgrenze an.
Hier kann man sich von weiteren Fehlern bzgl. dnf informieren. Wir reden hier vom "Herzstück" des Systems. Da wurde am lebendigen Menschen das gute Herz gegen ein krankhaftes ausgetauscht. Die Intention war sicherlich gut, allerdings bereitet dies jetzt mehr Probleme als Nutzen.
Da stellt sich die Frage, wie viele Fedora releases wir nun warten müssen, bis die use cases (welche JETZT durch yum erfüllt werden), nur im Ansatz von DNF erfüllt werden.
#13: dnf hängt sich mitten im prozess auf. es werden weder metadaten heruntergeladen noch werden dateien heruntergeladen bzw. installiert. einfach unerklärliche stille:
Stell dir vor, du stößt Abends einen Automatismus an, der am nächsten Morgen nicht einmal die Metadaten heruntergeladen hat.
Zahlreiche Bugs die von uns geöffnet wurden, wurden einfach so wieder dichtgemacht. Einige Entwickler wünschen ausagekräftige Use Cases, was natürlich zu Text führt. Andere Entwickler fühlen sich durch zu viel "Text" vollkommen genervt und schließen einfach. Da wird dann einfach auf das dnf Handbuch verwiesen und gut.
Problem: Es geht nicht nur um's Lesen der neuen Kommandos, sondern dnf verhält sich in vielen Bereichen auch vollkommen anders als das Gegenstück (auch Kommandomäßig) zu yum. Was die Entwickler (Junior) nicht begreifen, es existiert bereits sehr viel Inftrastruktur rund um yum, welche nun portiert werden muss. Denen, so meine Beobachtung, scheint nur ihr dnf im Vordergrund. Das es Menschen gibt, die System Integration betreiben und auch Ausgaben von yum (und spezielles Verhalten von yum) weiterverarbeiten - kommt dort nicht an.
Weiter im Kontext, auch wenn dieser Artikel schon für paar Tage aus der Reichweite ist. Dennoch wird sich der Eine oder Andere hier ein Bookmark gesetzt haben.
#10: dnf erkennt --installroot nicht vollkommen an. Es sieht --installroot nur als eine Stelle, wo man hininstalliert. Jedoch berücksichtigt es KEINE repositories die sich *auch wenn sie nur temporär sind* im /installroot/etc/yum.repos.d Verzeichnis. yum erkennt diesen Umstand an und nutzt daher auch die repos korrekt. Natürlich schön, wenn ein automatisierter Prozess auf Grund von Inkompatibilität vollkommen abbricht. Scripte die vorher jahrelang problemlos funktionierten. Kaputt.
#11: dnf builddep vs yum-builddep. Weiter einfernt können beide Kommandos nicht sein. Während yum die Abhängigkeiten vollständig auflöst und ALLE Abhängigkeiten herunterlädt, kann dnf zwar Abhängigkeiten auflösen, findet aber nicht ALLES, was zum Bauen von Paketen benörtig wird. Ergo: Nach dem Automatisieren, kann man erstmal selbst einige hundert Pakete per Hand nachinstallieren.
Bisher hat sich Fedora 22 als die unbequemste Fedorainstallation erwiesen. Schuld an der ganzen Sache ist in erster Linie das neue dnf.
Wir haben rund um yum eine komplette Infrastruktur gebildet, so dass wir die an uns gestellten Anforderungen gezielt erfüllen können. Das neue dnf ist leider nicht in der Lage, zahlreiche dieser Anforderungen zu bedienen. Meiner Ansicht nach, haben sich die Entwickler und um dnf maßlos übernommen bzw. ist dessen Einführung absolut verfrüht.
Es steht zwar weiterhin das yum als Ersatz zur Verfügung. Allerdings kommt der Auswurf "yum is deprecated" sicherlich nicht gut bei einer Produktvorstellung an.
Hier zahlreiche Fehlermeldungen rund um dnf:
#1: dnf ist nicht in der Lage, vernünftig im chroot Umgebungen zu arbeiten. Statt RPM Schlüssel zu übernehmen, bricht dnf einfach nur ab. Wenn man die Querverlinkungen durchliest, stellt sich sogar heraus, dass dnf nicht in der Lage war, nfs Nutzer anzulegen, gerade weil es abgestürzt ist (das gesamte Paket fehlte).
https://bugzilla.redhat.com/show_bug.cgi?id=1224908
#2: Unsere Anforderungen beötigen ein Äquivalent zu yumdb, um Attribute in der yumdb (Respektive dnfdb), setzen, löschen bzw. modifizieren zu können. Diese Funktionalität ist vollkommen nicht existent.
https://bugzilla.redhat.com/show_bug.cgi?id=1227949
#3: Verbose/Debug Ausgabe nicht bestimmt genug. Unsere Anforderungen benötigen eine Liste der heruntergeladenen Pakete. Mit yum -d 3 konnte man diese Liste per Ausgabe grep'en und weiterverarbeiten. Das neue dnf hat sich dieser Thematik vollständig entledigt. Ein vollständiger use case ist in folgenden Beschreibungen zu finden.
https://bugzilla.redhat.com/show_bug.cgi?id=1209638
https://bugzilla.redhat.com/show_bug.cgi?id=1203491
#4: Diesmal keine dnf Anforderung, sondern eine Anforderung an Virtualisierung. Zum Thema System Integration sind wir angehalten, virtuelle Maschinen zu nutzen. Das Installieren mittels Anaconda benötigt 3.5 Stunden auf normalen corporate Notebooks mit GIS Images. Die Verzögerung ist durch einen Fehler im GTK+ (Spinner) begründet. Statt das Flag für Anaconda auf "false" zu setzen (welches einen drastischen Performanzgewinn mit sich bringen würde), schiebt man sich per Argumentation nur gegenseitig die Schuld zu (naja nicht ganz).
https://bugzilla.redhat.com/show_bug.cgi?id=1223183
#5: Gnome-Shell kommt mit Netzwerkkarten nicht klar. Sobald man am Notebook mehr als ein WLAN betreibt (das Interne bzw. auch noch ein Externes), kommt Gnome-Shell nicht mehr klar. Die Netzwerke behindern sich gegenseitig. Will man eines von beiden abschalten, so schaltet sich das gesamte WLAN ab, schaltet man eines der Geräte wieder ein, schaltet sich das gesamte WLAN (und alle anderen Geräte wieder ein).
https://bugzilla.redhat.com/show_bug.cgi?id=1226039
Bisher kann ich nicht behaupten, dass mir Fedora 22 wirklich Spaß macht. Einige Fehler lassen sich durch Modifikationen umgehen. Am schlimmsten für uns ist die Tatsache das "dnf" leider nicht nutzbar ist.
#6: Soeben einen Drucker installiert. Leider lässt sich unter Gnome-Shell (und dessen Setup Tool) die Seite nicht von Letter auf A4 umstellen. Immer wieder springt die Auswahl auf Letter zurück. Durchaus geglückt. Ob ich hierfür noch einen Bugzilla Ticket aufmache. Ich habe echt keine Lust mehr dazu, da ich das System nutzen und nicht erstmal Alpha-Tester spielen möchte.
#7: Erststart von Gnome-Shell auf einem i3 Notebook x > 5 Minuten. Vermutlich Packagekit, Tracker und anderes Cache Gedöns.
#8: Abermals ein dnf Problem. dnf gibt gegenüber yum andere Rückgabewerte an die console zurück, so dass Scripte und Systeme, die rund um yum (dnf) geschrieben wurden, sich nun vollkommen anders verhalten. Laut Aussage sei dies so geplant. Nur führt es zu nichts, wenn sich 3rd party Anwendungen nun vollkommen falsch verhalten.
https://bugzilla.redhat.com/show_bug.cgi?id=1226135
#9: dnf builddep verhält sich vollkommen anders als yum-builddep. Es findet nicht Ansatzweise die vollständigen Abhängigkeiten. Wir rennen hier mit unseren Systemen von einem in den nächsten Fehler.
Wir ecken bereits an der Frustrationsgrenze an.
Hier kann man sich von weiteren Fehlern bzgl. dnf informieren. Wir reden hier vom "Herzstück" des Systems. Da wurde am lebendigen Menschen das gute Herz gegen ein krankhaftes ausgetauscht. Die Intention war sicherlich gut, allerdings bereitet dies jetzt mehr Probleme als Nutzen.
https://apps.fedoraproject.org/packages/dnf/bugs/all
Das tolle dnf... Der User merkt nix... Merk mal was.
Und weiter geht's
#12: (12 ?) Ok egal. Hier wieder eine Limitation eines für uns wichtigen Features. Alles das was yum bereits JETZT kann, kann dnf nicht.
https://bugzilla.redhat.com/show_bug.cgi?id=1229613
Da stellt sich die Frage, wie viele Fedora releases wir nun warten müssen, bis die use cases (welche JETZT durch yum erfüllt werden), nur im Ansatz von DNF erfüllt werden.
#13: dnf hängt sich mitten im prozess auf. es werden weder metadaten heruntergeladen noch werden dateien heruntergeladen bzw. installiert. einfach unerklärliche stille:
https://bugzilla.redhat.com/show_bug.cgi?id=1206878
https://bugzilla.redhat.com/show_bug.cgi?id=1214538
https://bugzilla.redhat.com/show_bug.cgi?id=1223803
https://bugzilla.redhat.com/show_bug.cgi?id=1229823
https://lists.fedoraproject.org/pipermail/devel/2015-June/211237.html
Stell dir vor, du stößt Abends einen Automatismus an, der am nächsten Morgen nicht einmal die Metadaten heruntergeladen hat.
Zahlreiche Bugs die von uns geöffnet wurden, wurden einfach so wieder dichtgemacht. Einige Entwickler wünschen ausagekräftige Use Cases, was natürlich zu Text führt. Andere Entwickler fühlen sich durch zu viel "Text" vollkommen genervt und schließen einfach. Da wird dann einfach auf das dnf Handbuch verwiesen und gut.
Problem: Es geht nicht nur um's Lesen der neuen Kommandos, sondern dnf verhält sich in vielen Bereichen auch vollkommen anders als das Gegenstück (auch Kommandomäßig) zu yum. Was die Entwickler (Junior) nicht begreifen, es existiert bereits sehr viel Inftrastruktur rund um yum, welche nun portiert werden muss. Denen, so meine Beobachtung, scheint nur ihr dnf im Vordergrund. Das es Menschen gibt, die System Integration betreiben und auch Ausgaben von yum (und spezielles Verhalten von yum) weiterverarbeiten - kommt dort nicht an.
Weiter im Kontext, auch wenn dieser Artikel schon für paar Tage aus der Reichweite ist. Dennoch wird sich der Eine oder Andere hier ein Bookmark gesetzt haben.
#10: dnf erkennt --installroot nicht vollkommen an. Es sieht --installroot nur als eine Stelle, wo man hininstalliert. Jedoch berücksichtigt es KEINE repositories die sich *auch wenn sie nur temporär sind* im /installroot/etc/yum.repos.d Verzeichnis. yum erkennt diesen Umstand an und nutzt daher auch die repos korrekt. Natürlich schön, wenn ein automatisierter Prozess auf Grund von Inkompatibilität vollkommen abbricht. Scripte die vorher jahrelang problemlos funktionierten. Kaputt.
https://bugzilla.redhat.com/show_bug.cgi?id=1229442
#11: dnf builddep vs yum-builddep. Weiter einfernt können beide Kommandos nicht sein. Während yum die Abhängigkeiten vollständig auflöst und ALLE Abhängigkeiten herunterlädt, kann dnf zwar Abhängigkeiten auflösen, findet aber nicht ALLES, was zum Bauen von Paketen benörtig wird. Ergo: Nach dem Automatisieren, kann man erstmal selbst einige hundert Pakete per Hand nachinstallieren.
https://bugzilla.redhat.com/show_bug.cgi?id=1229447
Wer immer DNF als Standard deklariert hat, muss entweder besoffen gewesen sein, ein Clown oder von der Materie absolut keine Ahnung haben.
Selbst die *do not break user experience* rule wurde hier vollkommen unter den Teppich gekehrt.