Mit der Fedora 28 Version scheint es einige Abstriche gegeben zu haben.
Ein Beitrag auf Phoronix.com zeigt auf, dass einige hundert Pakete des Fedora 28 Zweigs kein Update erfahren haben. Das, obwohl ein Branch und Massen-Neubau eingeleitet wurde. Dies jedoch mächtig schief ging und deren automatisierte "Build Platform" die Aufträge nicht angenommen haben.
Wochen nach dem Erscheinen der Beta Release von Fedora 28, waren weiterhin mehrere hundert Pakete im Fedora 28 Zweig veraltet bzw. nicht auf dem neusten Stand.
Daher stellte sich die Frage, ob man ein verlängertes Fedora 27 testete oder das tatsächliche Fedora 28.
Die Fragestellung ist berechtigt, da, die neuen Pakete und neuen Versionen von Programmen nicht wirklich getestet werden konnten. Dies betrift natürlich die Kompatibilität, Stabilität, Änderungen in der Ausführung per Kommandzeile usw.
Ich möchte das hier nur kurz angemerkt belassen. Wer mehr über den Sachverhalt lesen möchte, sei auf Phoronix.com verwiesen.
(Verweis auf Phoronix, da lange Links von Pro-Linux.de als lange Worte erkannt werden)
https://tinyurl.com/yaext7dq
(Candy) Kommentare #3, #5, #9
Und ein Statement eines Fedora Verantwortlichen, wo diese Probleme eingestanden wurden:
Kommentar #11
Auch jetzt befinden sich noch Altpakete aus Fedora 27 im offiziellen Fedora 28 Repository.
Wochen nach dem Erscheinen der Beta Release von Fedora 28, waren weiterhin mehrere hundert Pakete im Fedora 28 Zweig veraltet bzw. nicht auf dem neusten Stand.
Daher stellte sich die Frage, ob man ein verlängertes Fedora 27 testete oder das tatsächliche Fedora 28.
Die Fragestellung ist berechtigt, da, die neuen Pakete und neuen Versionen von Programmen nicht wirklich getestet werden konnten.
Natürlich können auch "Alt-Pakete" getestet werden: Die Vorabversionen enthalten schließlich auch diese nicht neu kompilierten Pakete.
Zum anderen ist die Frage, wie relevant die betroffenen Pakete wirklich waren. Auf meinem F28-System finden sich 2734 "fc28" Pakete und nur 33 mit "fc27". Da das ganze ein Upgrade von F27 war, dürften diverse Pakete "Upgrade-Fehler" sein, wo die F27-Version höher war als die F28-Version.
Insofern halte ich (aus Anwendersicht) die "fc27"-Problematik für irrelevant.
Fedora hat ein automatisches Ökosystem, wo man mit einfachen Kommandos ein "Neubauen" erzwingen kann. Dies ist u.A. auch verpflichtend für neue Fedora Versionen.
Wenn z.B. Fedora 29 gebaut werden soll, kann man das automatisch branchen und ein Massen-Neubau erzwingen. Dies veranlasst bereits, dass Changelog Einträge in den SPEC Dateien (eine beschreibende Datei zum Bauen der RPM Pakete) vorgenommen wird. Danach wird der Bauauftrag an KOJI weitergeleitet, wo das Paket dann gebaut und zur Verfügung gestellt wird.
Fedora hatte aber zeitgleich eine Änderung an ihrer Infrastruktur vorgenommen, was wohl (nach meiner Ansicht) den Fehler verursachte, das tausende von Pakete nicht gebaut wurden.
Dies beinhaltete nicht nur einfache SPEC Versionssprünge, sondern auch Software, die bereits einen major Versionssprung durchliefen. Z.B. fehlen etliche Pakete, wo die Software eigentlich hätte weiter sein müssen.
Es handelt sich wie gesagt um keinen "Upgrade Fehler", da die Problematik bereits von offizieller Seite bestätigt wurde. Es handelt sich um die offiziellen Pakete, wie sie in den Repositories vorgefunden werden.
Nur gut das man darüber nicht spricht. Das hat den Endnutzer sicherlich nicht zu interessieren
Fedora hat ein automatisches Ökosystem, wo man mit einfachen Kommandos ein "Neubauen" erzwingen kann. Dies ist u.A. auch verpflichtend für neue Fedora Versionen.
Inwiefern ist eine Neukompilierung "verpflichtend" für eine neue Fedora-Version? Ja, mir sind "mass rebuilds" bekannt und ja, es gibt auch die Policy, dass Pakete kompilierbar sein müssen, aber es gibt keine explizite Policy, dass jedes Paket für jede Fedora-Version neu gebaut werden muss. Falls ich mich hier falsch erinnere, wäre ich für eine Quelle dankbar.
Es handelt sich wie gesagt um keinen "Upgrade Fehler", da die Problematik bereits von offizieller Seite bestätigt wurde.
Ich wollte mit meinem Post nicht ausdrücken, dass es sich bei allen Paketen auf meinem System um Upgrade-Fehler handelte. Es ging mir um die Abschätzung, wie relevant dieses rebuild-Problem tatsächlich ist.
Insofern bezweifle ich, dass (Stand heute) im Fedora repo noch tausende Pakete existieren, die nicht für F28 neu gebaut wurden.
Nur gut das man darüber nicht spricht. Das hat den Endnutzer sicherlich nicht zu interessieren :)
Das klingt mir zu sehr nach "Verschwörungstheorie". Warum spricht "man" darüber nicht? Offenbar wurde es doch in den in Phoronix-Foren erwähnt und du hast es hier auch publiziert?
Wenn diese Nachricht aber nicht die Beachtung findet, die du dir wünschst, könntest du dich aber auch fragen, ob dieses Problem wirklich so bedeutend ist.
Fedora hat diverse Probleme, aber die konkreten Auswirkungen von rebuild-Problemen bei F28 halte ich in der Praxis für sehr gering.
Die Anforderungen über den Neubau von Paketen kann man irgendwo auf den Fedora Seiten nachlesen. Du wirst sicherlich Verständnis zeigen, das ich kein wandelndes Lexikon bzw. Archiv bin.
Im Übrigen - und wenn du dich bemühen tätest meinen Beitrag zu verstehen. Die Anweisung zum Neubau wurde doch eingeleietet. Die Pakete sind nur nie erschienen.
Steht doch alles mit Nachweisen auf der Phoronix Referenz.
Von Verfluchtnochmal-05995bd7b am Do, 3. Mai 2018 um 11:37 #
Und weiter?
Pakete hören nicht zwangsweise zu funktionieren auf nur weil sie nicht explizit neu gebaut wurden - Es gab mehr als ein Release wo explizit nur ein Subset der Core-Pakete mit dem neuen GCC gebaut wurde und sonst NICHTS, bewusst so entschieden
Ich denke ich konnte dir die Problematik nicht richtig vermitteln. Dafür möchte ich mich entschuldigen.
Es geht nicht darum, ob Pakete gebaut werden müssen oder nicht, sondern darum, dass die Pakete, die als Mass Rebuild für das Fedora 28 Release als Prozess eingeleitet wurden, nicht gebaut und geliefert wurden.
Beispiel: mc-4.8.20-2 hätte für Fedora 28 als Mass Rebuild Auftrag (seit Februar) gebaut werden müssen, da es beauftragt wurde.
Dieses Paket ist jedoch nie gebaut und geliefert worden.
Im Changelog des Fedora Git Repositories wurde das Paket zwar für Fedora 28 gebranched. Es wurde ein Changelog Eintrag vorgenommen. Das Paket wurde aber nie gebaut und geliefert, da die Infrastruktur am offenen Herzen verändert wurde.
Momentan müssen wir weiterhin mc-4.8.19-7 (Fedora 27) nutzen und konnten daher nie das 4.8.20-2 in der Beta und jetzt im Final testen.
Der Phoronix Beitrag des Users Candy zeigt weitere solcher Defizite auf, dessen Ursprung wohl auf die Infrastrukturumstellung zurückzuführen ist. Es geht hier nicht um 1-2 Pakete, die man vernachlässigen könnte. Sondern um viele hundert solcher Pakete (die man auch kaum im Bugzilla hätte berichten können).
Es geht hier überhaupt nicht um: - Irgendwelche Fedora Bauprozess-Regeln - Darum das das System nicht weiter einwandfrei funktioniert - Oder einem Schlechtmachen von Fedora.
Es geht hier nur um einen Hinweis, dass dieser Umstand präsent ist.
Das Fedora 28 funktioniert weiterhin einwandfrei. Selbst mit den "alten" Paketen. Nur gingen halt etliche Pakete unter bzw. wurden dieses Mal nicht geliefert.
Für den Einen Nutzer mag das wichtig sein, hat er/sie gewisse Erwartungen an ein Subset von Paketen gehegt, die zwar angekündigt, aber nie gebaut wurden. Dem anderen Nutzer mag das alles vollkommen egal sein.
Meiner Ansicht nach hätte man zuvor die Infrastrukturprobleme beseitigen und dann alle Pakete bauen müssen. Dies hätte dieses Problem sicherlich vermieden.
Der Upgrade von Fedora soll sich für alle Interessengruppen lohnen und nicht denen, die mal ein neues Gnome testen wollen. Unter dem Strich ist es das.
Ich denke ich konnte dir die Problematik nicht richtig vermitteln. Dafür möchte ich mich entschuldigen.
Zunächst einmal danke für diesen Beitrag, er ist tatsächlich (für mich) besser verständlich.
Es geht hier nur um einen Hinweis, dass dieser Umstand präsent ist.
Das Fedora 28 funktioniert weiterhin einwandfrei. Selbst mit den "alten" Paketen. Nur gingen halt etliche Pakete unter bzw. wurden dieses Mal nicht geliefert.
Für den Einen Nutzer mag das wichtig sein, hat er/sie gewisse Erwartungen an ein Subset von Paketen gehegt, die zwar angekündigt, aber nie gebaut wurden. Dem anderen Nutzer mag das alles vollkommen egal sein.
Meiner Ansicht nach hätte man zuvor die Infrastrukturprobleme beseitigen und dann alle Pakete bauen müssen. Dies hätte dieses Problem sicherlich vermieden.
Allerdings noch mal die Frage nach der Relevanz: Gibt es denn Anzeichen dafür, dass fehlgeschlagene bzw. nicht ausgeführte rebuilds ein Problem für den Nutzer bzw. die Qualität von F28 sind?
Dein ursprünglicher Post schien mir darauf abzuzielen:
Mit der Fedora 28 Version scheint es einige Abstriche gegeben zu haben.
Mir scheint das alles eher ein theoretisches Problem zu sein. Selbst wenn 10% der Pakete nicht neu gebaut wurden, wäre das doch nur ein kleiner Teil - zumal mir bislang kein wirklich wichtiges Paket aufgefallen ist, welches nicht neu gebaut wurde (dazu zählen für mich z.B.: kernel, gnome*, KDE, Python, gcc usw.).
fc27-Pakete auf meinem System sind eher solche, deren F28-Rebuild fehlschlug und die keinen aktiven Maintainer haben, der das Problem rechtzeitig behoben hätte.
Außerdem sehe ich eher Probleme in Maintainern, die in "stabilen" Fedora-Versionen zu aggressiv neue Versionen pushen, ohne sie ausreichend zu testen. Das ist aber unabhängig von irgendeiner rebuild-Problematik.
Von Verfluchtnochmal-05995bd7b am Do, 3. Mai 2018 um 12:49 #
Ach glaubst du das sind alles Idioten die nicht merken wenn was nicht neu gebaut wurde und dann Entscheidungen treffen können ob das jetzt unbedingt ein release-blocker ist oder nicht?
Du bist bei mir am falschen wenn du wem Fedora erklären willst, aktuell 40 Fedora-Installationen, viele davon deutlich über 10 Jahre und alle Dist-Upgrades mitgemacht, ja wir reden hier von Production-Servern und Workstations
Geschreiben auf einem Firefox 60 Fedora-Build - Koji hilft dir weiter..
> Ach glaubst du das sind alles Idioten die nicht > merken wenn was nicht neu gebaut wurde und > dann Entscheidungen treffen können ob das > jetzt unbedingt ein release-blocker ist oder > nicht?
Deine Ausage war nie Gegenstand des ursprünglichen Hinweises. Die Kompetenz der Entscheidungsträger und Mitwirkenden wurde doch nie in Frage gestellt.
Ich hätte mir nur einen besseren Umgang mit überlappender Infrastrukturanpassungen und Releasevorbereitungen gewünscht.
Einfach zur Sichtweise eines Endnutzers wechseln, der sich fragt, warum zahlreiche Pakete - die eigentlich gebaut werden sollten - fehlen.
Von Verfluchtnochmal-05995bd7b am Do, 3. Mai 2018 um 13:10 #
Und gerade bei Fedora ist es völlig wurscht ob das jetzt mc-4.8.19 oder mc-4.8.20 ausgeliefert wird am release Tag weil anders als bei Debian du solche Point-Updates ohnehin regulär bekommst
Weder F27 noch F28 wurden mit GCC 7.3.1 "ausgeliefert"
DNF ist die Paketverwaltung/ der Solver, der die Abhängigkeiten prüft und auflöst - das hat erst mal nichts mit dem Paketformat zu tun (.deb/ .rpm/ andere).
Beispiel: Debian und Derivate haben das DEB-Paketformat. Üblicherweise wird APT als Paketverwaltung benutzt (es ist aber auch mit anderen Paketverwaltungen möglich, DEB-Pakete zu verwalten!)
Red Hat und SUSE setzen auf das RPM-Paketformat. Red Hat verwendete früher YUM und heute DNF als Paketmanager. SUSE verwendete früher YAST und heute ZYPP, um die Pakete zu verwalten. Somit haben wir schon 4 Paketmanager, obwohl das Paketformat das gleiche ist.
Die Paketmanager können durchaus unterschiedlich sein in der Qualität der Abhängigkeitsauflösung und natürlich auch der Geschwindigkeit in der sie das tun. YUM z.B. hatte den Ruf, ziemlich langsam zu sein, DNF soll schneller sein.
Minimal langsamer, spielt aber überhaupt keine Rolle. Ich zumindest brauche eine saubere Basis auf die ich 100% setzen kann und keine Speedtoupdatewettkampfspinnerei die vollkommen sinnlos ist.
Alles super.
Mit der Fedora 28 Version scheint es einige Abstriche gegeben zu haben.
Ein Beitrag auf Phoronix.com zeigt auf, dass einige hundert Pakete des Fedora 28 Zweigs kein Update erfahren haben. Das, obwohl ein Branch und Massen-Neubau eingeleitet wurde. Dies jedoch mächtig schief ging und deren automatisierte "Build Platform" die Aufträge nicht angenommen haben.
Wochen nach dem Erscheinen der Beta Release von Fedora 28, waren weiterhin mehrere hundert Pakete im Fedora 28 Zweig veraltet bzw. nicht auf dem neusten Stand.
Daher stellte sich die Frage, ob man ein verlängertes Fedora 27 testete oder das tatsächliche Fedora 28.
Die Fragestellung ist berechtigt, da, die neuen Pakete und neuen Versionen von Programmen nicht wirklich getestet werden konnten. Dies betrift natürlich die Kompatibilität, Stabilität, Änderungen in der Ausführung per Kommandzeile usw.
Ich möchte das hier nur kurz angemerkt belassen. Wer mehr über den Sachverhalt lesen möchte, sei auf Phoronix.com verwiesen.
(Verweis auf Phoronix, da lange Links von Pro-Linux.de als lange Worte erkannt werden)
https://tinyurl.com/yaext7dq
(Candy)
Kommentare #3, #5, #9
Und ein Statement eines Fedora Verantwortlichen, wo diese Probleme eingestanden wurden:
Kommentar #11
Auch jetzt befinden sich noch Altpakete aus Fedora 27 im offiziellen Fedora 28 Repository.
> da lange Links von Pro-Linux.de als lange Worte erkannt werden
Man darf Links aber auch als Links verlinken
– dann geht’s auch mit den langen!
Natürlich können auch "Alt-Pakete" getestet werden: Die Vorabversionen enthalten schließlich auch diese nicht neu kompilierten Pakete.
Zum anderen ist die Frage, wie relevant die betroffenen Pakete wirklich waren. Auf meinem F28-System finden sich 2734 "fc28" Pakete und nur 33 mit "fc27". Da das ganze ein Upgrade von F27 war, dürften diverse Pakete "Upgrade-Fehler" sein, wo die F27-Version höher war als die F28-Version.
Insofern halte ich (aus Anwendersicht) die "fc27"-Problematik für irrelevant.
Nein!
Fedora hat ein automatisches Ökosystem, wo man mit einfachen Kommandos ein "Neubauen" erzwingen kann. Dies ist u.A. auch verpflichtend für neue Fedora Versionen.
Wenn z.B. Fedora 29 gebaut werden soll, kann man das automatisch branchen und ein Massen-Neubau erzwingen. Dies veranlasst bereits, dass Changelog Einträge in den SPEC Dateien (eine beschreibende Datei zum Bauen der RPM Pakete) vorgenommen wird. Danach wird der Bauauftrag an KOJI weitergeleitet, wo das Paket dann gebaut und zur Verfügung gestellt wird.
Fedora hatte aber zeitgleich eine Änderung an ihrer Infrastruktur vorgenommen, was wohl (nach meiner Ansicht) den Fehler verursachte, das tausende von Pakete nicht gebaut wurden.
Dies beinhaltete nicht nur einfache SPEC Versionssprünge, sondern auch Software, die bereits einen major Versionssprung durchliefen. Z.B. fehlen etliche Pakete, wo die Software eigentlich hätte weiter sein müssen.
Es handelt sich wie gesagt um keinen "Upgrade Fehler", da die Problematik bereits von offizieller Seite bestätigt wurde. Es handelt sich um die offiziellen Pakete, wie sie in den Repositories vorgefunden werden.
Nur gut das man darüber nicht spricht. Das hat den Endnutzer sicherlich nicht zu interessieren
Inwiefern ist eine Neukompilierung "verpflichtend" für eine neue Fedora-Version? Ja, mir sind "mass rebuilds" bekannt und ja, es gibt auch die Policy, dass Pakete kompilierbar sein müssen, aber es gibt keine explizite Policy, dass jedes Paket für jede Fedora-Version neu gebaut werden muss. Falls ich mich hier falsch erinnere, wäre ich für eine Quelle dankbar.
Ich wollte mit meinem Post nicht ausdrücken, dass es sich bei allen Paketen auf meinem System um Upgrade-Fehler handelte.
Es ging mir um die Abschätzung, wie relevant dieses rebuild-Problem tatsächlich ist.
Fakten:
- 2734 fc28-Pakete auf meinem Desktop-Rechner (Upgrade F27->F28)
- 33 fc27-Pakete (~ 1,2%)
Insofern bezweifle ich, dass (Stand heute) im Fedora repo noch tausende Pakete existieren, die nicht für F28 neu gebaut wurden.
Das klingt mir zu sehr nach "Verschwörungstheorie". Warum spricht "man" darüber nicht? Offenbar wurde es doch in den in Phoronix-Foren erwähnt und du hast es hier auch publiziert?
Wenn diese Nachricht aber nicht die Beachtung findet, die du dir wünschst, könntest du dich aber auch fragen, ob dieses Problem wirklich so bedeutend ist.
Fedora hat diverse Probleme, aber die konkreten Auswirkungen von rebuild-Problemen bei F28 halte ich in der Praxis für sehr gering.
> Insofern bezweifle ich, dass (Stand heute) im
> Fedora repo noch tausende Pakete existieren,
> die nicht für F28 neu gebaut wurden.
Lies doch die Beiträge auf Phoronix.
dnf update --refresh
cd /var/cache/dnf/fedora-f21308f6293b3270/repodata/
zcat *filelists.xml.gz | grep "< version.*fc27" | wc -l
Vielleicht müsstest du die Hash-Nummer anpassen. Aus aktueller Sicht ist der Rückgabewert 3481 Pakete.
zcat *filelists.xml.gz | grep "Von insgesamt 57317 Pakete in der Repository. Nicht mitgezählt sind die Updates und Updates-Testing etc. Repositories.
Die relative Prozentzahl wäre ((1 - (3481 / 57317)) * 100) = 6.073%
Die Anforderungen über den Neubau von Paketen kann man irgendwo auf den Fedora Seiten nachlesen. Du wirst sicherlich Verständnis zeigen, das ich kein wandelndes Lexikon bzw. Archiv bin.
Im Übrigen - und wenn du dich bemühen tätest meinen Beitrag zu verstehen. Die Anweisung zum Neubau wurde doch eingeleietet. Die Pakete sind nur nie erschienen.
Steht doch alles mit Nachweisen auf der Phoronix Referenz.
Und weiter?
Pakete hören nicht zwangsweise zu funktionieren auf nur weil sie nicht explizit neu gebaut wurden - Es gab mehr als ein Release wo explizit nur ein Subset der Core-Pakete mit dem neuen GCC gebaut wurde und sonst NICHTS, bewusst so entschieden
Ich denke ich konnte dir die Problematik nicht richtig vermitteln. Dafür möchte ich mich entschuldigen.
Es geht nicht darum, ob Pakete gebaut werden müssen oder nicht, sondern darum, dass die Pakete, die als Mass Rebuild für das Fedora 28 Release als Prozess eingeleitet wurden, nicht gebaut und geliefert wurden.
Beispiel:
mc-4.8.20-2 hätte für Fedora 28 als Mass Rebuild Auftrag (seit Februar) gebaut werden müssen, da es beauftragt wurde.
Dieses Paket ist jedoch nie gebaut und geliefert worden.
Im Changelog des Fedora Git Repositories wurde das Paket zwar für Fedora 28 gebranched. Es wurde ein Changelog Eintrag vorgenommen. Das Paket wurde aber nie gebaut und geliefert, da die Infrastruktur am offenen Herzen verändert wurde.
Momentan müssen wir weiterhin mc-4.8.19-7 (Fedora 27) nutzen und konnten daher nie das 4.8.20-2 in der Beta und jetzt im Final testen.
Der Phoronix Beitrag des Users Candy zeigt weitere solcher Defizite auf, dessen Ursprung wohl auf die Infrastrukturumstellung zurückzuführen ist. Es geht hier nicht um 1-2 Pakete, die man vernachlässigen könnte. Sondern um viele hundert solcher Pakete (die man auch kaum im Bugzilla hätte berichten können).
Es geht hier überhaupt nicht um:
- Irgendwelche Fedora Bauprozess-Regeln
- Darum das das System nicht weiter einwandfrei funktioniert
- Oder einem Schlechtmachen von Fedora.
Es geht hier nur um einen Hinweis, dass dieser Umstand präsent ist.
Das Fedora 28 funktioniert weiterhin einwandfrei. Selbst mit den "alten" Paketen. Nur gingen halt etliche Pakete unter bzw. wurden dieses Mal nicht geliefert.
Für den Einen Nutzer mag das wichtig sein, hat er/sie gewisse Erwartungen an ein Subset von Paketen gehegt, die zwar angekündigt, aber nie gebaut wurden. Dem anderen Nutzer mag das alles vollkommen egal sein.
Meiner Ansicht nach hätte man zuvor die Infrastrukturprobleme beseitigen und dann alle Pakete bauen müssen. Dies hätte dieses Problem sicherlich vermieden.
Der Upgrade von Fedora soll sich für alle Interessengruppen lohnen und nicht denen, die mal ein neues Gnome testen wollen. Unter dem Strich ist es das.
Zunächst einmal danke für diesen Beitrag, er ist tatsächlich (für mich) besser verständlich.
Allerdings noch mal die Frage nach der Relevanz: Gibt es denn Anzeichen dafür, dass fehlgeschlagene bzw. nicht ausgeführte rebuilds ein Problem für den Nutzer bzw. die Qualität von F28 sind?
Dein ursprünglicher Post schien mir darauf abzuzielen:
Mir scheint das alles eher ein theoretisches Problem zu sein. Selbst wenn 10% der Pakete nicht neu gebaut wurden, wäre das doch nur ein kleiner Teil - zumal mir bislang kein wirklich wichtiges Paket aufgefallen ist, welches nicht neu gebaut wurde (dazu zählen für mich z.B.: kernel, gnome*, KDE, Python, gcc usw.).
fc27-Pakete auf meinem System sind eher solche, deren F28-Rebuild fehlschlug und die keinen aktiven Maintainer haben, der das Problem rechtzeitig behoben hätte.
Außerdem sehe ich eher Probleme in Maintainern, die in "stabilen" Fedora-Versionen zu aggressiv neue Versionen pushen, ohne sie ausreichend zu testen. Das ist aber unabhängig von irgendeiner rebuild-Problematik.
Ach glaubst du das sind alles Idioten die nicht merken wenn was nicht neu gebaut wurde und dann Entscheidungen treffen können ob das jetzt unbedingt ein release-blocker ist oder nicht?
Du bist bei mir am falschen wenn du wem Fedora erklären willst, aktuell 40 Fedora-Installationen, viele davon deutlich über 10 Jahre und alle Dist-Upgrades mitgemacht, ja wir reden hier von Production-Servern und Workstations
Geschreiben auf einem Firefox 60 Fedora-Build - Koji hilft dir weiter..
> Ach glaubst du das sind alles Idioten die nicht
> merken wenn was nicht neu gebaut wurde und
> dann Entscheidungen treffen können ob das
> jetzt unbedingt ein release-blocker ist oder
> nicht?
Deine Ausage war nie Gegenstand des ursprünglichen Hinweises. Die Kompetenz der Entscheidungsträger und Mitwirkenden wurde doch nie in Frage gestellt.
Ich hätte mir nur einen besseren Umgang mit überlappender Infrastrukturanpassungen und Releasevorbereitungen gewünscht.
Einfach zur Sichtweise eines Endnutzers wechseln, der sich fragt, warum zahlreiche Pakete - die eigentlich gebaut werden sollten - fehlen.
Nicht mehr und nicht weniger.
Ernsthaft? Der typische "Endbenutzer" fragt sich genau gar nichts weil er aus genau dem Grund eine Distribution und nicht LFS benutzt
Bei der ganzen Diskussion sind wir zumindest einen guten Schritt weiter gekommen. Danke.
Und gerade bei Fedora ist es völlig wurscht ob das jetzt mc-4.8.19 oder mc-4.8.20 ausgeliefert wird am release Tag weil anders als bei Debian du solche Point-Updates ohnehin regulär bekommst
Weder F27 noch F28 wurden mit GCC 7.3.1 "ausgeliefert"
gcc-7.3.1-2.fc26.x86_64
gcc-7.3.1-5.fc27.x86_64
Das mag durchaus zutreffen. Allerdings artet der Verlauf der Diskussion aus, da wir vom Thema abkommen.
Es ging hier lediglich um einen Hinweis (der nun hinreichend begründet wurde), dass Pakete fehlen.
Damit wurde eigentlich alles, was dem Aussagewillen entsprach, ausgedrückt.
toll schon version 8.01 von gcc
aber warum gibt es noch keine mingw version davon ? wann
kann es sein dass das updaten von rpm packeten am langsamsten abläuft auf einem pc ? im vergleich zu zb deb or arch packeten ?
hat jemand gemessen verglichen ?
Ist mir beim F27 mit dnf auch aufgefallen. Ich dachte das liegt zumindest an meinem 10 Jahre altem Laptop
dnf ist das irgend so ein Nachfolger von rpm ? aber gleich rpm ?
beim android kommen auch manchmal kleinere teilsupdates von apps
dnf ist der "schnellere" (arbeitende) und "wartbarere" Nachfolger von yum. Ein Paketmanager ähnlich wie apt-get, aptitude für Fedora.
RPM ist nur das Paketformat mit eigener RPM Datenbank.
https://fedoraproject.org/wiki/DNF/de
Es ist wie APT in Debian für .deb oder zypper in openSuSE für .rpm.
DNF ist die Paketverwaltung/ der Solver, der die Abhängigkeiten prüft und auflöst - das hat erst mal nichts mit dem Paketformat zu tun (.deb/ .rpm/ andere).
Beispiel:
Debian und Derivate haben das DEB-Paketformat.
Üblicherweise wird APT als Paketverwaltung benutzt (es ist aber auch mit anderen Paketverwaltungen möglich, DEB-Pakete zu verwalten!)
Red Hat und SUSE setzen auf das RPM-Paketformat.
Red Hat verwendete früher YUM und heute DNF als Paketmanager. SUSE verwendete früher YAST und heute ZYPP, um die Pakete zu verwalten. Somit haben wir schon 4 Paketmanager, obwohl das Paketformat das gleiche ist.
Die Paketmanager können durchaus unterschiedlich sein in der Qualität der Abhängigkeitsauflösung und natürlich auch der Geschwindigkeit in der sie das tun. YUM z.B. hatte den Ruf, ziemlich langsam zu sein, DNF soll schneller sein.
"Irgendso ein Nachfolger" - WTF - Ist es
echt zuviel verlangt sich wenigstens rudimentär zu informieren oder einfach den Rand zu halten?
rpm spielt in der gleichen Liga wie deb und dnf wie der Vorgänger yum auf der Ebene von
apt
Minimal langsamer, spielt aber überhaupt keine Rolle. Ich zumindest brauche eine saubere Basis auf die ich 100% setzen kann und keine Speedtoupdatewettkampfspinnerei die vollkommen sinnlos ist.