Hi, es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Ich will quasi einen --include Befehl, der aber den Manpages nach nicht implementiert ist. Hat da jemand eine Idee?
Roland
On Wed, 7 Jul 2004 13:12:02 +0000, Roland Wolters wrote:
Hi, es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Ich will quasi einen --include Befehl, der aber den Manpages nach nicht implementiert ist. Hat da jemand eine Idee?
1) Option -c und eine separate Configdatei angeben, in der nur die gewünschten Repositories stehen, und gegebenfalls selektiv Pakete auswählen für "yum -y install/update". Denn wenn das in --include stehende Paket Abhängigkeiten im gleichen Repositories hätte, würdest Du diese Abhängigkeiten doch auch installiert haben wollen.
2) rpm -ivh http://...
Once upon a time Michael Schwendt wrote:
On Wed, 7 Jul 2004 13:12:02 +0000, Roland Wolters wrote:
es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Ich will quasi einen --include Befehl, der aber den Manpages nach nicht implementiert ist. Hat da jemand eine Idee?
- Option -c und eine separate Configdatei angeben, in der nur die
gewünschten Repositories stehen, und gegebenfalls selektiv Pakete auswählen für "yum -y install/update". Denn wenn das in --include stehende Paket Abhängigkeiten im gleichen Repositories hätte, würdest Du diese Abhängigkeiten doch auch installiert haben wollen.
Ich kann der Argumnetation nicht folgen - denn den exclude Befehl gibt es. Auf diesen angewandt, müsste ich damit ja ebenfalls Probleme kriegen.
Roland
On Wed, 7 Jul 2004 21:10:46 +0000, Roland Wolters wrote:
Once upon a time Michael Schwendt wrote:
On Wed, 7 Jul 2004 13:12:02 +0000, Roland Wolters wrote:
es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Ich will quasi einen --include Befehl, der aber den Manpages nach nicht implementiert ist. Hat da jemand eine Idee?
- Option -c und eine separate Configdatei angeben, in der nur die
gewünschten Repositories stehen, und gegebenfalls selektiv Pakete auswählen für "yum -y install/update". Denn wenn das in --include stehende Paket Abhängigkeiten im gleichen Repositories hätte, würdest Du diese Abhängigkeiten doch auch installiert haben wollen.
Ich kann der Argumnetation nicht folgen - denn den exclude Befehl gibt es. Auf diesen angewandt, müsste ich damit ja ebenfalls Probleme kriegen.
Genau. Pakete, die von exclude abgedeckt sind, stehen auch nicht zum Erfüllen von Abhängigkeiten bereit. Installation von Paketen kann dadurch scheitern. Mit einem include Konzept würdest Du noch einen Schritt weiter in Richtung manueller Installation von Paketen gehen.
On Wed, Jul 07, 2004 at 01:12:02PM +0000, Roland Wolters wrote:
Hi, es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Ich will quasi einen --include Befehl, der aber den Manpages nach nicht implementiert ist. Hat da jemand eine Idee?
apt hat ein priorities-System, bei dem man vergleichbares einrichten kann. Löst allerdings auch nicht jede Situation.
Gruß, Axel.
Once upon a time Axel Thimm wrote:
On Wed, Jul 07, 2004 at 01:12:02PM +0000, Roland Wolters wrote:
es geht um folgendes: Um Probleme zwischen verschiedenen Repositories zu vermeiden, nutze ich exzessiv die --exclude Funktion von yum aus. Nun stellt sich mir die Frage, ob man das nicht auch umdrehen kann? Gibt es eine Möglichkeit, z.B. '--exclude=' so umzufunktionieren, dass nur Paket xy aus dem Repo geladen wird, aber nicht alle anderen ab, cd, ef?
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Darum geht es im Endeffekt: um die "politischen Gründe" - da bringt alles bugzill'n nichts.
Aber trotzdem danke für die Antwort.
Roland
On Wed, 7 Jul 2004 21:11:27 +0000, Roland Wolters wrote:
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Darum geht es im Endeffekt: um die "politischen Gründe" - da bringt alles bugzill'n nichts.
Hast Du es schonmal probiert?
Once upon a time Michael Schwendt wrote:
On Wed, 7 Jul 2004 21:11:27 +0000, Roland Wolters wrote:
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Darum geht es im Endeffekt: um die "politischen Gründe" - da bringt alles bugzill'n nichts.
Hast Du es schonmal probiert?
Nein, weil es keinen Sinn macht in den Fällen, die ich meine - als Parade Beispiel:
Ich nutze KDE, und somit auch die KDE-RedHat Repos - dies gibt eine Inkompatibilität, die kaum lösbar erscheint - wenn ich aus dem KDE-RedHat Pakete ziehe, und gleichzeitig aus dem RedHat Standard Verzeichnis, dann geht mir KDE über Kurz oder Lang in die Knie, weil z.B. RedHat schneller neue Paketversionen draußen hat (->automatisches Update von dort), dann aber KDE-RedHat nachzieht (wieder update von dort). Probleme, die daraus entstanden, waren zum Teil schlichtweg unauflösbare Abhängigkeiten (weil einiges in KDE RedHat drin ist, was RedHat nicht mitbringt), zum anderen vermurkste Menüs, vermurkste Icons und andere merkwürdige Effekte (z.B. konnte kmenuedit sich nichts merken, alles "Speichern" klicken nutzte nichts).
Außerdem /will/ ich auch gar nicht irgendwelche KDE Pakete aus RedHat main - warum auch, wenn ich KDE-RedHat nutze? Wie sollte ich das anders als durch den exclude Befehl erledigen?
Intention ist für mich also, dass ich mit den exclude Regeln (die ich schon nutze) und den include Regeln (die ich gerne hätte), meine yum.conf so konfiguriere, dass ich z.B. alle Pakete, die auch in KDE-RedHat geführt werden, nur dort heraus aktualisiere (--exclude=kde* ... beim RedHat Hauptrepo), und dass ich eben für andere Pakete bestimmte andere Repositories wähle, und mir dort das raussuche, was ich haben will.
Bugzilla bringt hier herzlich wenig, da ich wohl kaum RedHat dazu bringen kann, die MP3-Lizenz Politik, die ich sehr gut verstehe, zu ändern. Und
Naja, vielleicht ist jetzt etwas klarer, wie ich zu dem Gedanken gekommen bin, ich werde aber in Zukunft auch mal genauer drauf achten, ob es immer politische Gründe sind, oder ob es nicht auch mit Bugzilla geht.
Danke aber für die Antworten.
Roland
On Thu, Jul 08, 2004 at 11:28:06AM +0000, Roland Wolters wrote:
Once upon a time Michael Schwendt wrote:
On Wed, 7 Jul 2004 21:11:27 +0000, Roland Wolters wrote:
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Darum geht es im Endeffekt: um die "politischen Gründe" - da bringt alles bugzill'n nichts.
Hast Du es schonmal probiert?
Nein, weil es keinen Sinn macht in den Fällen, die ich meine - als Parade Beispiel:
Ich nutze KDE, und somit auch die KDE-RedHat Repos - dies gibt eine Inkompatibilität, die kaum lösbar erscheint - wenn ich aus dem KDE-RedHat Pakete ziehe, und gleichzeitig aus dem RedHat Standard Verzeichnis, dann geht mir KDE über Kurz oder Lang in die Knie, weil z.B. RedHat schneller neue Paketversionen draußen hat (->automatisches Update von dort), dann aber KDE-RedHat nachzieht (wieder update von dort).
Die Probleme kenne ich auch, aber das sind wirklich keine politischen Probleme, sprich sie sind sicher lösbar.
Bugzilla bringt hier herzlich wenig, da ich wohl kaum RedHat dazu bringen kann, die MP3-Lizenz Politik, die ich sehr gut verstehe, zu ändern. Und
Dann bugzilla gegen kde-redhat. kde-redhat nutzt das gemeinsame bugzilla von einem weiteren Duzent repos bei bugzilla.atrpms.net. Es gab schonmal die Kritik, daß bugzilla und Listen bei ATrpms nicht zu Genüge promoted werden, also habe ich mal den Betreff angepaßt ...
Naja, vielleicht ist jetzt etwas klarer, wie ich zu dem Gedanken gekommen bin, ich werde aber in Zukunft auch mal genauer drauf achten, ob es immer politische Gründe sind, oder ob es nicht auch mit Bugzilla geht.
Die kde-redhat Maintainer reagieren sehr schnell auf solche Problematik. Es handelt es sich auch nicht um eine Inkompatibilität zwischen Repo X und Y, sondern zum Mutterschiff, was kein Repo auf sich ruhen lassen wird!
Aber auch gerade Probleme zwischen repos können und sollen bei bugzilla.atrpms.net eingetragen werden, da man die entsprechenden Repo Maintainer gleich ins Cc legen kann.
Bemerkung am Rande: Bugzilla bei bugzilla.atrpms.net wird im klassischen Sinne zum Bugreporting verwendet (für diejenigen die bugzilla von fedora.us her als Entscheidungsapparat für Paketveröffentlichungen her kennen).
Diskussionen über Pakete finden meist in den jeweiligen Listen statt (freshrpms, kde-redhat-*, atrpms-* usw.), doch das soll niemanden hindern bugzilla.atrpms.net nach eigenem Ermessen zu nutzen (nur bitte auf Englisch).
Gruß, Axel.
Once upon a time Axel Thimm wrote:
On Thu, Jul 08, 2004 at 11:28:06AM +0000, Roland Wolters wrote:
Once upon a time Michael Schwendt wrote:
On Wed, 7 Jul 2004 21:11:27 +0000, Roland Wolters wrote:
Möglicherweise wäre es leichter die Repos anzusprechen und zu bugzilla'n, daß es solche Konflikte gibt?
Es gibt natürlich leider einige Kombinationen, die sich aus politischen Gründen nicht nahkommen wollen. In dem Fall hat man Pech gehabt, aber die meisten Repo-Tupel sind willens mögliche Kombatibilitätsproblem aus der Welt zu schaffen.
Darum geht es im Endeffekt: um die "politischen Gründe" - da bringt alles bugzill'n nichts.
Hast Du es schonmal probiert?
Nein, weil es keinen Sinn macht in den Fällen, die ich meine - als Parade Beispiel:
Ich nutze KDE, und somit auch die KDE-RedHat Repos - dies gibt eine Inkompatibilität, die kaum lösbar erscheint - wenn ich aus dem KDE-RedHat Pakete ziehe, und gleichzeitig aus dem RedHat Standard Verzeichnis, dann geht mir KDE über Kurz oder Lang in die Knie, weil z.B. RedHat schneller neue Paketversionen draußen hat (->automatisches Update von dort), dann aber KDE-RedHat nachzieht (wieder update von dort).
Die Probleme kenne ich auch, aber das sind wirklich keine politischen Probleme, sprich sie sind sicher lösbar.
Das verstehe ich rein technisch nicht: Wenn durch die Pakete des KDE-RedHat Projektes die Struktur des Menüs mit voller Absicht verwendet wird, um die etwas KDE getreuer zu machen, wie soll ich dann da etwas lösen?
Denn wenn ich dann ein Update von RedHat mache, ist die Struktur der Menüs wieder in alter Form, was ich nicht will, oder sehe ich da was falsch? Ich wüsste nicht, in wie weit man das als Bug bezeichnen sollte...
Was das bugzilla bei atrpms.net angeht: da fehlen dann aber wieder fedora.us und livna.org. Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Rol*noch immer nach --include suchend*and
On Thu, 8 Jul 2004 13:49:36 +0000, Roland Wolters wrote:
Was das bugzilla bei atrpms.net angeht: da fehlen dann aber wieder fedora.us und livna.org. Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Nun, zuerstmal müßte jemand existierende Probleme melden. Erst dann ließe sich feststellen, ob sie technischer oder politischer Natur sind und wie sie sich lösen ließen.
Der Übergang zwischen technischer zur politischer Ebene ist jedoch fließend. Falls z.B. von vornherein keine Bereitschaft vorhanden ist, technische Ursachen zu beheben, wird so ein Problem zu einem politischen Problem. Technische Probleme, z.B. inoffizielle Upgrades von Fedora Core, die Abhängigkeiten brechen oder zu ungetesteten Konfigurationen führen, haben meist politischen Ursprung.
Wirklich interessant wird dieses Thema, wenn Fedora Extras offiziellen Status erhält.
Once upon a time Michael Schwendt wrote:
On Thu, 8 Jul 2004 13:49:36 +0000, Roland Wolters wrote:
Was das bugzilla bei atrpms.net angeht: da fehlen dann aber wieder fedora.us und livna.org. Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Nun, zuerstmal müßte jemand existierende Probleme melden. Erst dann ließe sich feststellen, ob sie technischer oder politischer Natur sind und wie sie sich lösen ließen.
[...]
Wirklich interessant wird dieses Thema, wenn Fedora Extras offiziellen Status erhält.
Ist bekannt, wann dem so weit ist? Gibt es eine Roadmap, die halbwegs aktuell ist? Und eine Übersicht, was dann genau wie von wem für Fedora.Extras gepackt wird? Und was alles drin sein wird, und warum?
Roland
Am Do, den 08.07.2004 schrieb Roland Wolters um 15:49:
Die Probleme kenne ich auch, aber das sind wirklich keine politischen Probleme, sprich sie sind sicher lösbar.
Denn wenn ich dann ein Update von RedHat mache, ist die Struktur der Menüs wieder in alter Form, was ich nicht will, oder sehe ich da was falsch? Ich wüsste nicht, in wie weit man das als Bug bezeichnen sollte...
Im Normalfall passiert das nicht, das das KDE-Redhat-Repo immer zeitgleich aktualisiert, d.h. dass sich die Redhat- und die KDE-Redhat-Pakete nicht in die Quere kommen.
Was das bugzilla bei atrpms.net angeht: da fehlen dann aber wieder fedora.us und livna.org. Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
André
On Thu, Jul 08, 2004 at 02:42:21PM +0200, André Kelpe wrote:
Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
Hey, sei nicht so pessimistisch. :)
Ich kann mir gut vorstellen, daß demnächst eine fedora.us interne leise Revolution stattfinden kann. Einige der key-developer in fedora.us suchen das Gespräch mit der Welt außerhalb des Tellerrandes auf.
Die Premisse, daß die freien Repos wegen nicht monolithischem Aufbau zugrunde gehen würden, hat sich nach 2 Jahren nun doch nicht befürwortet, im Gegenteil, die alten Repos haben an Popularität gewonnen, und viele junge Repos haben sich hinzugesellt. Das sehen auch die objektiveren Beobachter und wundern sich, wieso man sich durch Isolation bei fedora.us das Leben schwerer als nötig macht.
Unter'm Strich sieht es inzwischen sogar so aus, daß RH selbst die Kompatibilität zu einigen der größeren Repos wahrt und eine Koordination stattfindet (man siehe xfstools, freeglut, gaim, etc.). Wenn's sogar RH möglich ist, wieso nicht fedora.us? Also auf zur Revolution! ;)
Bevor "jemand" ;) mit Trompeten und Posaunen darauf aufmerksam macht, daß zwischen den freien Repos doch Inkompatibilitäten technischer und politischer Art auftreten können und aufgetreten sind (und das ist nur natürlich), so sind diese relativ zur genannten großen Kompatibiltätshürde zu fedora.us, sowie der Fülle der in der Summe angebotenen Pakete vernachläßigbar klein :)
Das erinnert alles an Kathedrale und Bazaar. Mal sehen, wann der Papst Gemüse einkaufen kommen wird ;)
Gruß, Axel.
Am Do, den 08.07.2004 schrieb Axel Thimm um 15:00:
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
Hey, sei nicht so pessimistisch. :)
Ok Ok, man sollte aber dennoch die Benutzer mehr auf solche Dinge aufmerksam machen. Ich persönlich bin alter FreshRPMS-Benutzer, und habe natürlich auch mittlerweile mehr Repos in meiner sources.list (ja, apt mag ich auch lieber ;-)), und ich empfehle auch jedem diese Kombination, sollte jmd. Linux testen wollen. Bisher hat sich auch noch niemand beschwert, weshalb ich davon ausgehe, dass der Rat richtig war.
Ich kann mir gut vorstellen, daß demnächst eine fedora.us interne leise Revolution stattfinden kann. Einige der key-developer in fedora.us suchen das Gespräch mit der Welt außerhalb des Tellerrandes auf.
Das wäre allerdings eine Revolution, und es würde dazu beitragen Fedora stärker erscheinen zu lassen (nach außen hin).
Die Premisse, daß die freien Repos wegen nicht monolithischem Aufbau zugrunde gehen würden, hat sich nach 2 Jahren nun doch nicht befürwortet, im Gegenteil, die alten Repos haben an Popularität gewonnen, und viele junge Repos haben sich hinzugesellt.
Hmm, erinnert mich irgendwie an die Diskussion Microkernel vs. monolithischer Kernel (na wer hat gewonnen?).
Das sehen auch die objektiveren Beobachter und wundern sich, wieso man sich durch Isolation bei fedora.us das Leben schwerer als nötig macht.
Das ist bei solchen Entscheidungen nicht verwunderlich, dass es auf Unverständnis stößt, vor allem weil fedora.us ja nicht die ersten waren, die es "auf dem Markt" gab.
Das erinnert alles an Kathedrale und Bazaar. Mal sehen, wann der Papst Gemüse einkaufen kommen wird ;)
Bazaar gewinnt, sonst würden wir hier nicht miteinander reden...
Gruß, Axel.
Grüße André
On Thu, Jul 08, 2004 at 03:20:18PM +0200, André Kelpe wrote:
Am Do, den 08.07.2004 schrieb Axel Thimm um 15:00:
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
Hey, sei nicht so pessimistisch. :)
Ok Ok, man sollte aber dennoch die Benutzer mehr auf solche Dinge aufmerksam machen.
Das auf jeden Fall, meinE Bemerkung bezog sich auf die Projektion auf die Zukunft ;)
Ich persönlich bin alter FreshRPMS-Benutzer, und habe natürlich auch mittlerweile mehr Repos in meiner sources.list (ja, apt mag ich auch lieber ;-)), und ich empfehle auch jedem diese Kombination, sollte jmd. Linux testen wollen. Bisher hat sich auch noch niemand beschwert, weshalb ich davon ausgehe, dass der Rat richtig war.
War er ja auch, keine Zweifel. Ich habe zwar nun öfter von erfolgreichen Cross-Kombinationen zwischen freien Repos und fedora.us gehört (vor allem aus der ATrpms Ecke), und das ist schon ein gutes Signal, doch kann ich das eben nicht garantieren, und fedora.us erst Recht nicht.
Ich kann mir gut vorstellen, daß demnächst eine fedora.us interne leise Revolution stattfinden kann. Einige der key-developer in fedora.us suchen das Gespräch mit der Welt außerhalb des Tellerrandes auf.
Das wäre allerdings eine Revolution, und es würde dazu beitragen Fedora stärker erscheinen zu lassen (nach außen hin).
Die Premisse, daß die freien Repos wegen nicht monolithischem Aufbau zugrunde gehen würden, hat sich nach 2 Jahren nun doch nicht befürwortet, im Gegenteil, die alten Repos haben an Popularität gewonnen, und viele junge Repos haben sich hinzugesellt.
Hmm, erinnert mich irgendwie an die Diskussion Microkernel vs. monolithischer Kernel (na wer hat gewonnen?).
Micorkernel natürlich, zähl doch mal die kernel module rpms auf Deinem System ;)
Das sehen auch die objektiveren Beobachter und wundern sich, wieso man sich durch Isolation bei fedora.us das Leben schwerer als nötig macht.
Das ist bei solchen Entscheidungen nicht verwunderlich, dass es auf Unverständnis stößt, vor allem weil fedora.us ja nicht die ersten waren, die es "auf dem Markt" gab.
Das erinnert alles an Kathedrale und Bazaar. Mal sehen, wann der Papst Gemüse einkaufen kommen wird ;)
Bazaar gewinnt, sonst würden wir hier nicht miteinander reden...
Gruß, Axel.
Once upon a time Axel Thimm wrote:
On Thu, Jul 08, 2004 at 02:42:21PM +0200, André Kelpe wrote:
Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
Hey, sei nicht so pessimistisch. :)
Ich kann mir gut vorstellen, daß demnächst eine fedora.us interne leise Revolution stattfinden kann. Einige der key-developer in fedora.us suchen das Gespräch mit der Welt außerhalb des Tellerrandes auf.
Unabhängig davon, wer wie revolutionieren muss, kann ich als Nutzer, der vielen anderen Nutzern bei den Problemen immer wieder helfen darf, nur darauf verweisen, dass die Revolution an sich langsam aber sicher, nach bald einem Jahr Fedora Core und jetzt bei der dritten Version im Test-Tree, überfällig ist.
Ich kann mir gut vorstellen, dass man auf Dauer Unterschriften zusammen sammelt oder sonst was, um einfach mal auf beide Seiten etwas Druck auszuüben - frei nachdem Motto: Vielfalt ist gut, aber sie muss kompatibel bleiben. ich weiss, dass viele auch auf Fedora Extras warten, und man danach wohl erst richtig loslegen kann, die Richtlinien auszuarbeiten, etc. Aber es erweckt trotzdem einen komischen Eindruck auf Neulinge, und auch ich grübel ab und an etwas über den Status quo....
Just me 2 cents,
Rol*der die Suche nach --include übrigens jetzt aufgegeben hat, aber allen für ihre Kommentare dankt*and
On Thu, Jul 08, 2004 at 04:32:35PM +0000, Roland Wolters wrote:
Once upon a time Axel Thimm wrote:
On Thu, Jul 08, 2004 at 02:42:21PM +0200, André Kelpe wrote:
Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Letztlich liegt bei jedem die grundlegende Entscheidung: fedora.us + livna, oder Freshrpms, atrpms, newrpms, dag etc. Evtl. sollte man darauf mehr aufmerksam machen, aber es muss sich jeder bewusst sein, dass er eine Kompatiblitätsentscheidung zu treffen hat. Natürlich ist das unschön, aber wird sich wohl auch in naher Zukunft nicht ändern.
Hey, sei nicht so pessimistisch. :)
Ich kann mir gut vorstellen, daß demnächst eine fedora.us interne leise Revolution stattfinden kann. Einige der key-developer in fedora.us suchen das Gespräch mit der Welt außerhalb des Tellerrandes auf.
Unabhängig davon, wer wie revolutionieren muss, kann ich als Nutzer, der vielen anderen Nutzern bei den Problemen immer wieder helfen darf, nur darauf verweisen, dass die Revolution an sich langsam aber sicher, nach bald einem Jahr Fedora Core und jetzt bei der dritten Version im Test-Tree, überfällig ist.
Und in Wirklichkeit geht es noch auf RH9 Zeiten zurück (oder sogar RH8.0?). Das ist alles nur zu wahr, am Ende sitzt der User wie verarscht da. :(
Ich kann mir gut vorstellen, dass man auf Dauer Unterschriften zusammen sammelt oder sonst was, um einfach mal auf beide Seiten etwas Druck auszuüben
Ist natürlich die Frage, welche Forderungen man auf die freien Repos ausüben will, bzw. was man von Ihnen erwartet, was nicht schon gegen ist. Die Ablehnung einer Zusammenarbeit kommt ja nicht von deren Seite, und die seltenen (!) Forderungen an diese waren bestenfalls als "laßt Eure repos bei fedora.us einverleiben" zu verstehen.
- frei nachdem Motto: Vielfalt ist gut, aber sie muss kompatibel bleiben.
Von Deinem Reden in Gottes Ohr ;)
ich weiss, dass viele auch auf Fedora Extras warten, und man danach wohl erst richtig loslegen kann, die Richtlinien auszuarbeiten, etc. Aber es erweckt trotzdem einen komischen Eindruck auf Neulinge, und auch ich grübel ab und an etwas über den Status quo....
Just me 2 cents,
Rol*der die Suche nach --include übrigens jetzt aufgegeben hat, aber allen für ihre Kommentare dankt*and
Once upon a time André Kelpe wrote:
Am Do, den 08.07.2004 schrieb Roland Wolters um 15:49:
Die Probleme kenne ich auch, aber das sind wirklich keine politischen Probleme, sprich sie sind sicher lösbar.
Denn wenn ich dann ein Update von RedHat mache, ist die Struktur der Menüs wieder in alter Form, was ich nicht will, oder sehe ich da was falsch? Ich wüsste nicht, in wie weit man das als Bug bezeichnen sollte...
Im Normalfall passiert das nicht, das das KDE-Redhat-Repo immer zeitgleich aktualisiert, d.h. dass sich die Redhat- und die KDE-Redhat-Pakete nicht in die Quere kommen.
Das ist mir neu, das habe ich vorher nicht nachvollziehen können - sonst wäre ich ja auch nie auf die Idee gekommen, den --exclude Befehl einzubetten. Leider lässt es sich aktuell nur schwer nachvollziehen, da KDE-RedHat bereits auf KDE 3.2.3 setzt.
Roland
On Thu, Jul 08, 2004 at 01:49:36PM +0000, Roland Wolters wrote:
Once upon a time Axel Thimm wrote:
On Thu, Jul 08, 2004 at 11:28:06AM +0000, Roland Wolters wrote:
Ich nutze KDE, und somit auch die KDE-RedHat Repos - dies gibt eine Inkompatibilität, die kaum lösbar erscheint - wenn ich aus dem KDE-RedHat Pakete ziehe, und gleichzeitig aus dem RedHat Standard Verzeichnis, dann geht mir KDE über Kurz oder Lang in die Knie, weil z.B. RedHat schneller neue Paketversionen draußen hat (->automatisches Update von dort), dann aber KDE-RedHat nachzieht (wieder update von dort).
Die Probleme kenne ich auch, aber das sind wirklich keine politischen Probleme, sprich sie sind sicher lösbar.
Das verstehe ich rein technisch nicht: Wenn durch die Pakete des KDE-RedHat Projektes die Struktur des Menüs mit voller Absicht verwendet wird, um die etwas KDE getreuer zu machen, wie soll ich dann da etwas lösen?
Denn wenn ich dann ein Update von RedHat mache, ist die Struktur der Menüs wieder in alter Form, was ich nicht will, oder sehe ich da was falsch? Ich wüsste nicht, in wie weit man das als Bug bezeichnen sollte...
Also ein Bug ist es auf jeden Fall, wenn Dein Desktop irgendwie kaputtgemacht wird.
Zum konkreten Fall: Obwohl ich selbst keine KDE-Desktop/Menü Benutzer bin, habe ich oft gesehen, daß die Installation von redhat-menus0 empfohlen wird.
Oder Du hast einen neuen Bug und gerade den gilt es zu melden.
Was das bugzilla bei atrpms.net angeht: da fehlen dann aber wieder fedora.us und livna.org.
Die man gerne in bugzilla.atrpms.net aufnehmen würde, sofern diese Projekte das wünschen würden. Es macht wirklich sehr viel Sinn gemeinsame bugzillas zu verwenden. Bugs können dann z.B. von einem Repo zum anderen leicht migriert werden. Bzw. gemeinsame Bugs bei mehreren Repo-Verantwortlichen eingetragen werden.
Und das ist dann wieder, so weit wie ich das verstehe, die politische Ebene, in der ich als quasi-unwissender der politischen Probleme sicher keine Bugs über "inkompatibilitäten" posten möchte, um nicht zwischen den Fronten zermahlen zu werden.
Das ist richtig. Hier liegt das Problem darin, daß sich fedora.us von Anfang an vom Rest der Repos abgeschnürt hat und bewußt nicht Kompatibilitäten ansprechen wollte.
Es wäre schön, wenn fedora.us dieses fallen lassen würde und mehr mit den anderen kooperieren würde. Bereitschaft zur Zusammenarbeit von allen anderen Repos gab es zu Genüge angeboten in den letzten 1.5 Jahren. Nur kann natürlich Zusammenarbeit nicht einseitig sein.
Meine Einschätzung ist die, daß inzwischen nur noch sehr wenige Hardcoremitglieder in fedora.us (und fedora-de ;) sitzen, die die Zusammenarbeit immer noch ablehnen. Ich sehe das als fedora.us internes Problem an. Man kann dort die Diskussion anstoßen, doch lösen müssen fedora.us Köpfe es selbst.
Mal sehen, vielleicht gibt's doch ein Happy End, und fedora.us öffnet sich dem Rest der Welt ;) </friedefreudeeierkuchen>
de-users@lists.fedoraproject.org