Nach dem Fiasko mit YUM vs. DNF, bin ich mir nicht mehr so sicher, ob ich weiterhin bei Fedora bleibe.
Fedora ansich ist eine sehr gute Distribution. Von vielen getesteten Distributionen, meiner Ansicht nach eines der Bestintegrierten.
Allerdings hat man mit dem Wechsel von YUM auf DNF den Vogel abgeschossen. Nichts mehr funktioniert, wie es ursprünglich einmal war.
Wir (Mehrzahl) haben über die Jahre zahlreiche auf YUM aufsetzende Skripte entwickelt, die unsere Prozesse der Systemintegration vereinheitlichen und vereinfachen.
Kaum eines dieser Skripte funktioniert mehr. Einige Skripte ließen sich umschreiben, andere hingegen nicht (weil die Features einfach fehlen).
Währenddessen habe ich jegliche Kommunikation mit den Entwicklern (auf Bugzilla) eingestellt, da ich einfach keine Zeit und auch kein Interesse an weitergehender Kommunikation mit diesen Leuten pflege.
Aufwändig formulierte und aufgesetzte Use Cases werden innerhalb von Minuten, nachdem sie auf Bugzilla erschienen, von den Developern mit blödsinnigen Kommentaren und Annahmen dichtgemacht.
Quasi läuft alles auf ein "You are holding it wrong" hinaus. Funktionen und Features die einst mittels YUM da waren, sind nicht existent. Statt diese neu zu implementieren, wird man auf die tolle DNF API verwiesen (damit man sich das neu schreiben darf).
Uns geht es nicht um das Neuschreiben oder die tolle DNF API. Fakt ist, das wir unsere Infrastruktur bereits seit Jahren nutzen und diese nicht "noch aufwändiger" umschreiben möchten. Anpassen ja! Umschreiben Nein!.
Die o.g. Bugs sind noch nicht das Ende. Mit DNF 1.0.2-3 (Fedora 22) wurde auch die Verzeichnisstruktur der Cache Dateien von YUM angepasst.
Vorher war alles im /var/cache/dnf/22/i386/ untergebracht. Dies hat man nun alles ins top Verzeichnis gepackt.
/var/cache/dnf/[hier alles rein]
Weitere unsere Skripte, die Anpassungen benötigen (obwohl solche Anpassungen einfach nicht sein dürfen, sobald ein Fedora Release als stabil herausgegeben wurden: Siehe Releaseanforderungen).
Während yum install http://...*.rpm also der Verweis auf eine RPM Datei im Netz, diese Datei mittels korrektem Filenamen in ein separates yum Verzeichnis herunterlädt. Läd DNF die gleiche Datei ins /tmp/2314124.rpm herunter. Also die Dateinnamen sind futsch und das gesamte /tmp/ Verzeichnis wird dichtgemüllt.
Ich kann verstehen, dass dir dieser Umstand Probleme bereitet.
Aber meinst du nicht, dass Fedora für euch die falsche Wahl ist, und ihr bei RedHat bzw. CentOS besser aufgehoben wärt? Ich nutze auf meinem normalen Alltagsnotebook ( Da läuft auch nur git, PyCharm, vim, Firefox und die Standard-Anwendungen halt drauf ) Fedora, auf meiner richtigen Workstation läuft aus den von dir genannten Gründen CentOS
Eigentlich war/ist Fedora nicht die falsche Wahl, da wir Systemintegration für RPM basierende Systeme betreiben, die auf YUM aufsetzen. Kurz- bis Mittelfristig werden wohl RHEL und CentOS auf den DNF Zug auffahren müssen.
DNF ansich ist per-se erstmal nicht schlecht. Bietet es langfristig den erhofften Support als auch die Vereinheitlichung einiger Softwaremanager.
Ärgerlich an der Sache ist nur, dass DNF einfach ziemlich weit vom YUM Schuss weg ist. Sich vollkommen anders verhält usw.
DNF stellt gegenwärtig eine Herausforderung an uns dar, die wir auf Grund fehlender Implementierung nicht bedienen können. Mittelfristig stellt sich demnach auch die Frage, ob diese "Features" je implementiert werden (was bereits bei einigen Dingen verneint wurde).
Debian steht momentan als Option an, da wir für weitere Experimente solcher Art, wie sie gegenwärtig bei Fedora anzufinden sind, nicht bereit sind. Ärgerlich an der Sache ist, dass wir von RPM basierten Systemen vollständig auf DEB umsteigen müssten (hierzu existieren jedoch noch die alten Skripte, die wir damals schrieben).
Was ist Gnome 28?
Was soll GNOME 28 sein?
Wenn du 2.8 meinst - Ähm GNOME 3.x anyone?
... die HartzIV Version ...
Nach dem Fiasko mit YUM vs. DNF, bin ich mir nicht mehr so sicher, ob ich weiterhin bei Fedora bleibe.
Fedora ansich ist eine sehr gute Distribution. Von vielen getesteten Distributionen, meiner Ansicht nach eines der Bestintegrierten.
Allerdings hat man mit dem Wechsel von YUM auf DNF den Vogel abgeschossen. Nichts mehr funktioniert, wie es ursprünglich einmal war.
Wir (Mehrzahl) haben über die Jahre zahlreiche auf YUM aufsetzende Skripte entwickelt, die unsere Prozesse der Systemintegration vereinheitlichen und vereinfachen.
Kaum eines dieser Skripte funktioniert mehr. Einige Skripte ließen sich umschreiben, andere hingegen nicht (weil die Features einfach fehlen).
Ausführlich habe ich das hier dargestellt:
http://www.pro-linux.de/artikel/2/1775/comm/577920/
Währenddessen habe ich jegliche Kommunikation mit den Entwicklern (auf Bugzilla) eingestellt, da ich einfach keine Zeit und auch kein Interesse an weitergehender Kommunikation mit diesen Leuten pflege.
Aufwändig formulierte und aufgesetzte Use Cases werden innerhalb von Minuten, nachdem sie auf Bugzilla erschienen, von den Developern mit blödsinnigen Kommentaren und Annahmen dichtgemacht.
Quasi läuft alles auf ein "You are holding it wrong" hinaus. Funktionen und Features die einst mittels YUM da waren, sind nicht existent. Statt diese neu zu implementieren, wird man auf die tolle DNF API verwiesen (damit man sich das neu schreiben darf).
Uns geht es nicht um das Neuschreiben oder die tolle DNF API. Fakt ist, das wir unsere Infrastruktur bereits seit Jahren nutzen und diese nicht "noch aufwändiger" umschreiben möchten. Anpassen ja! Umschreiben Nein!.
Die o.g. Bugs sind noch nicht das Ende. Mit DNF 1.0.2-3 (Fedora 22) wurde auch die Verzeichnisstruktur der Cache Dateien von YUM angepasst.
Vorher war alles im /var/cache/dnf/22/i386/ untergebracht. Dies hat man nun alles ins top Verzeichnis gepackt.
/var/cache/dnf/[hier alles rein]
Weitere unsere Skripte, die Anpassungen benötigen (obwohl solche Anpassungen einfach nicht sein dürfen, sobald ein Fedora Release als stabil herausgegeben wurden: Siehe Releaseanforderungen).
Während yum install http://...*.rpm also der Verweis auf eine RPM Datei im Netz, diese Datei mittels korrektem Filenamen in ein separates yum Verzeichnis herunterlädt. Läd DNF die gleiche Datei ins /tmp/2314124.rpm herunter. Also die Dateinnamen sind futsch und das gesamte /tmp/ Verzeichnis wird dichtgemüllt.
Echt ärgerlich bis an die Frustrationsgrenze.
Ich kann verstehen, dass dir dieser Umstand Probleme bereitet.
Aber meinst du nicht, dass Fedora für euch die falsche Wahl ist, und ihr bei RedHat bzw. CentOS besser aufgehoben wärt? Ich nutze auf meinem normalen Alltagsnotebook ( Da läuft auch nur git, PyCharm, vim, Firefox und die Standard-Anwendungen halt drauf ) Fedora, auf meiner richtigen Workstation läuft aus den von dir genannten Gründen CentOS
Eigentlich war/ist Fedora nicht die falsche Wahl, da wir Systemintegration für RPM basierende Systeme betreiben, die auf YUM aufsetzen. Kurz- bis Mittelfristig werden wohl RHEL und CentOS auf den DNF Zug auffahren müssen.
DNF ansich ist per-se erstmal nicht schlecht. Bietet es langfristig den erhofften Support als auch die Vereinheitlichung einiger Softwaremanager.
Ärgerlich an der Sache ist nur, dass DNF einfach ziemlich weit vom YUM Schuss weg ist. Sich vollkommen anders verhält usw.
DNF stellt gegenwärtig eine Herausforderung an uns dar, die wir auf Grund fehlender Implementierung nicht bedienen können. Mittelfristig stellt sich demnach auch die Frage, ob diese "Features" je implementiert werden (was bereits bei einigen Dingen verneint wurde).
Debian steht momentan als Option an, da wir für weitere Experimente solcher Art, wie sie gegenwärtig bei Fedora anzufinden sind, nicht bereit sind. Ärgerlich an der Sache ist, dass wir von RPM basierten Systemen vollständig auf DEB umsteigen müssten (hierzu existieren jedoch noch die alten Skripte, die wir damals schrieben).