Versionen
überleg dir mal, wieso suse einen aufwand treiben sollte, einen neuen firefox auf ein suse 7.* zu integrieren ?
Hallo,
kann das nicht auch politische Gründe haben? In der Vergangenheit waren die Verzeichnisbäume der Distribution und er Updates immer getrennt und du hattest *nie* bei SuSE eine neue Hauptversion im Update-Zweig, nur Patches zu der Version der jerweiligen Distributionsversion.
Das muß aber doch theoretisch nicht so sein, denn die Binary-Distributions von Firefox kannst du auch unter ältern SuSEn (ok, 7.x habe ich nicht probiert, aber 9.x) einfach auspacken und fertich.
Man könnte innerhalb von SuSE durchaus einen festen Pfad zu Firefox haben und eine RPM anbieten, die genau das tut, oder sehe ich das falsch? Debian kann ja sogar über apt mit einem simplen Upate im Freiflug Firefox durch Icedove ersetzen, es ist einfach eine Frage, was in dem RPM auf dem SuSE-Update-Server für die jeweilige SuSE-Version drin ist. Das könnte problemlos in /usr/share/firefox eine 1.x.x durch eine 2.x ersetzen, wenn das denn gewollt wäre. Glaube ich jedenfalls.
Insofern untermauert dein Beispiel deine These nicht, weil es durchaus denkbar währe, eine ständig vor sich hin wachsende SuSE-Distri anzubieten.
Debian hat doch sowas mit "Sid" und da wandern dauernd "Testing"-Zweige draus ab, die dann irgend wann "stable" sind und damit "die Debian-Distribution" werden.
In einer Binary-Dist wird halt viel Zeit in konsistente Pfade und Abhängigkeiten gesteckt, die der User dann spart, weil er nicht alles kompilieren muß. Aber daß deshalb keine "Major-Upgrades" innerhalb älterer Distro-Versionen passieren, ist doch eher gewollt als nötig, oder irre ich da?
Das Argument ist doch wohl eher: Wenn immer nur *Sources* die Grundlage sind, entfällt die Einpflege in die Distribution, aber genau die Aufgabe landet dann beim User. Das ist nicht per se falsch, wenn der User genau das wissen will. Dann ist doch gerade genau das richtig.
