Ich würde mir weiterhin wünschen, dass eine weitere Kompatibilität zu YUM erreicht wird.
Gegenwärtig hat DNF noch einige Inkompatibilitäten zu YUM, so dass wohl viele Skripte nicht richtig mit DNF funktionieren, wie sie es mit YUM taten.
Gerade im Umfeld dessen, dass Fedora / RHEL und CentOS immer mehr Einzug auch in Unternehmen finden (z.b. im Rahmen von Systemintegration), so werden Firmen sicherlich auch Systemintegrateure beschäftigen, die mit Hilfe von Eigenentwicklungen spezielle Systeme für Kunden anpassen.
Daher war es sehr unbedacht, das YUM zu deprecaten und anstelle dessen DNF zu setzen.
Probleme, die wir selbst mit DNF leider noch haben.
a) Rückgabewerte von DNF unterscheiden sich mit denen von YUM. Das haben wir für unser System (welches jahrelang mit YUM lief) z.B. in den Griff bekommen. Dennoch sind hier die Werte anders und konnten nicht korrekt verarbeitet werden.
b) Eines der größten Probleme die wir mit DNF noch haben - und was uns leider weiterhin an YUM kettet - ist, dass DNF kein --downloaddir kennt und wir zwingend darauf angewiesen sind. Das DNF download Plugin kennt zwar ein ähnliches Kommando --downdir, jedoch kann das Plugin keine Metapakete (Gruppen) verarbeiten. Bisher leider keine Alternative zu YUM.
c) Es gab da noch zahlreiche Sachen, die uns - gerade am Anfang - sehr viele Probleme bereiteten. Debug und Verbose Ausgaben waren bei DNF leider sehr limitiert, so dass wir - so wie wir unser System entwickelten - leider die Debug Ausgaben nicht mehr verarbeiten konnten. Die Daten wurden nicht geliefert. Auch hier haben wir mühevoll einen neuen alternativen Ansatz entwickeln müssen.
d) --skip-broken. Unser System brach ab (bewusste Funktion), wenn Abhängigkeiten nicht resolved wurden. Das garantierte uns, dass die bereits heruntergeladenen Pakete allesamt abhängig und konsistent waren. Mit DNF ist das leider nicht mehr möglich, da Pakete, die die Abhängigkeit nicht erfüllten, einfach von sich aus geskippt werden. Da wir die gesamten Pakete in ihrer Gesamtheit verarbeiten und prüfen, kann es vorkommen, dass das Ergeniss nicht weiterverarbeitbar ist - in unserem Prozess jedenfalls.
e) DNF hält während eines Update Prozesses an und läuft nicht weiter. Da kann es passieren, das DNF einfach stundenlang nix tut und auch nicht abbricht.
f) Im Chroot kommt DNF nicht mit RPM Keys klar und haut einen Fehler raus. Daher muss man immer --nogpgcheck eingeben, damit DNF weiterarbeitet. Leider werden hierbei die Keys nicht verarbeitet.
Wir haben nun seit ca. 1 Jahr oder so, sehr viele Bugs und RFE's im Bugzilla hierzu geöffnet - die Sachverhalte und Use-Cases auch sehr im Detail beschrieben. Leider wurden die meisten Bugs und RFE's in nur wenigen Momenten einfach so dichtgemacht. Eine Kommunikation mit den Entwicklern gestaltet sich als sehr schwierig - und führe dazu, dass wir Fesco und den Fedora Projektleitder mit unserem Anliegen kontaktieren mussten.
Man versprach uns eine bessere "Kompatibilität" zu YUM. Allerdings fehlen weiterhin elementare Funktionen wie das "händeringende" gebrauchte --downloaddir im DNF Hauptpaket.
Gerade im unternehmerischen Einsatz ist es unverständlich, wie man eines der Kernelemente einer Distribution - den Paketmanager - in eine Art und Weise verändert, dass dies zwangsläufig zum "Brechen" von weiterer Infrastruktur und sonstigen Dingen führt.
Ich möchte mit dieser Erfahrung die wir hatten, nun nicht das Gespräch anzetteln, wie "Open Source" zu funktionieren hat usw.. Es geht darum, dass man sich hier vorher hätte Gedanken zu machen sollen. Letztendlich sollte es auch im Interesse von Red Hat selbst liegen, ob ihre Produkte (später mal RHEL, welches wohl DNF anbietet), nicht zum Bruch von weiterer Infrastruktur bei Kunden führt. Wenn Skripte plötzlich nicht mehr funktionieren usw.
So eine ähnliche Diskussion kam kürzlich auf Heise.de (oder Golem.de), wo RPM unter die Lupe genommen wurde. Da wurden feste Bestandteile des RedHats an die Öffentlichkeit abgegeben und endete mit "Bruch" (ich habe die Konversation nur am Rande mitverfolgt).
Die gesamte Fedora, RHEL und CentOS Infrastruktur, wie Pungi, Mock und einige weitere Systeme (die Releases und ISO Images bauen), verwenden zwangsweise weiterhin YUM.
Leider hat YUM mittlerweile Probleme bekommen, was WEAK DEPENENCIES betrifft, so dass auch hier schon alles am Krachen ist.
Wir sind zwar alle für DNF... Aber es muss wesentlich kompatibler zu YUM werden - und auch die fehlenden Kommandozeilenoptionen zurückerhalten.
Ich würde mir weiterhin wünschen, dass eine weitere Kompatibilität zu YUM erreicht wird.
Gegenwärtig hat DNF noch einige Inkompatibilitäten zu YUM, so dass wohl viele Skripte nicht richtig mit DNF funktionieren, wie sie es mit YUM taten.
Gerade im Umfeld dessen, dass Fedora / RHEL und CentOS immer mehr Einzug auch in Unternehmen finden (z.b. im Rahmen von Systemintegration), so werden Firmen sicherlich auch Systemintegrateure beschäftigen, die mit Hilfe von Eigenentwicklungen spezielle Systeme für Kunden anpassen.
Daher war es sehr unbedacht, das YUM zu deprecaten und anstelle dessen DNF zu setzen.
Probleme, die wir selbst mit DNF leider noch haben.
a) Rückgabewerte von DNF unterscheiden sich mit denen von YUM. Das haben wir für unser System (welches jahrelang mit YUM lief) z.B. in den Griff bekommen. Dennoch sind hier die Werte anders und konnten nicht korrekt verarbeitet werden.
b) Eines der größten Probleme die wir mit DNF noch haben - und was uns leider weiterhin an YUM kettet - ist, dass DNF kein --downloaddir kennt und wir zwingend darauf angewiesen sind. Das DNF download Plugin kennt zwar ein ähnliches Kommando --downdir, jedoch kann das Plugin keine Metapakete (Gruppen) verarbeiten. Bisher leider keine Alternative zu YUM.
c) Es gab da noch zahlreiche Sachen, die uns - gerade am Anfang - sehr viele Probleme bereiteten. Debug und Verbose Ausgaben waren bei DNF leider sehr limitiert, so dass wir - so wie wir unser System entwickelten - leider die Debug Ausgaben nicht mehr verarbeiten konnten. Die Daten wurden nicht geliefert. Auch hier haben wir mühevoll einen neuen alternativen Ansatz entwickeln müssen.
d) --skip-broken. Unser System brach ab (bewusste Funktion), wenn Abhängigkeiten nicht resolved wurden. Das garantierte uns, dass die bereits heruntergeladenen Pakete allesamt abhängig und konsistent waren. Mit DNF ist das leider nicht mehr möglich, da Pakete, die die Abhängigkeit nicht erfüllten, einfach von sich aus geskippt werden. Da wir die gesamten Pakete in ihrer Gesamtheit verarbeiten und prüfen, kann es vorkommen, dass das Ergeniss nicht weiterverarbeitbar ist - in unserem Prozess jedenfalls.
e) DNF hält während eines Update Prozesses an und läuft nicht weiter. Da kann es passieren, das DNF einfach stundenlang nix tut und auch nicht abbricht.
f) Im Chroot kommt DNF nicht mit RPM Keys klar und haut einen Fehler raus. Daher muss man immer --nogpgcheck eingeben, damit DNF weiterarbeitet. Leider werden hierbei die Keys nicht verarbeitet.
Wir haben nun seit ca. 1 Jahr oder so, sehr viele Bugs und RFE's im Bugzilla hierzu geöffnet - die Sachverhalte und Use-Cases auch sehr im Detail beschrieben. Leider wurden die meisten Bugs und RFE's in nur wenigen Momenten einfach so dichtgemacht. Eine Kommunikation mit den Entwicklern gestaltet sich als sehr schwierig - und führe dazu, dass wir Fesco und den Fedora Projektleitder mit unserem Anliegen kontaktieren mussten.
Man versprach uns eine bessere "Kompatibilität" zu YUM. Allerdings fehlen weiterhin elementare Funktionen wie das "händeringende" gebrauchte --downloaddir im DNF Hauptpaket.
Gerade im unternehmerischen Einsatz ist es unverständlich, wie man eines der Kernelemente einer Distribution - den Paketmanager - in eine Art und Weise verändert, dass dies zwangsläufig zum "Brechen" von weiterer Infrastruktur und sonstigen Dingen führt.
Ich möchte mit dieser Erfahrung die wir hatten, nun nicht das Gespräch anzetteln, wie "Open Source" zu funktionieren hat usw.. Es geht darum, dass man sich hier vorher hätte Gedanken zu machen sollen. Letztendlich sollte es auch im Interesse von Red Hat selbst liegen, ob ihre Produkte (später mal RHEL, welches wohl DNF anbietet), nicht zum Bruch von weiterer Infrastruktur bei Kunden führt. Wenn Skripte plötzlich nicht mehr funktionieren usw.
So eine ähnliche Diskussion kam kürzlich auf Heise.de (oder Golem.de), wo RPM unter die Lupe genommen wurde. Da wurden feste Bestandteile des RedHats an die Öffentlichkeit abgegeben und endete mit "Bruch" (ich habe die Konversation nur am Rande mitverfolgt).
Die gesamte Fedora, RHEL und CentOS Infrastruktur, wie Pungi, Mock und einige weitere Systeme (die Releases und ISO Images bauen), verwenden zwangsweise weiterhin YUM.
Leider hat YUM mittlerweile Probleme bekommen, was WEAK DEPENENCIES betrifft, so dass auch hier schon alles am Krachen ist.
Wir sind zwar alle für DNF... Aber es muss wesentlich kompatibler zu YUM werden - und auch die fehlenden Kommandozeilenoptionen zurückerhalten.
Danke für euren Einsatz.