On Mon, 3 May 2004 13:08:09 +0200, Patrice Brockhaus wrote: Warum "natürlich"? ;) Synaptic/AptRpm ist bei Dir so konfiguriert, daß es auf den Fedora Core 1.92 oder gar den Development Tree zugegreift? Vielleicht hat Mozilla-1.6-0 aus Dags repo aber auch eine höhere "Epoch" und wird deshalb als neuer behandelt. Schwer zu beantworten. Die aktuellsten Pakete sind selten die besten bzw. stabilsten. Oder sie sind für eine neuere Distribution. Und obwohl sie sich auf einer älteren Distribution installieren lassen, sind sie in der Umgebung nicht getestet und laufen möglicherweise nicht problemlos, weil sie von Bug-Fixes in anderen Paketen abhängen. latest = 1.92 Du kannst es probieren, aber siehe oben. Wahrscheinlich ziehen Dir Paketabhängigkeiten dann Schritt für Schritt Pakete aus 1.92 herein. Und letztendlich erhältst Du dann eine Mixtur aus Fedora Core 1 und Fedora Core 2 Test 3. Ersters ja, letzteres nein. RPMS.os = Fedora Core RPMS.updates = Fedora Core Updates (official) RPMS.updates-testing = Fedora Core Test Updates RPMS.stable = Fedora Extras von fedora.us RPMS.testing = Fedora Extras von fedora.us RPMS.unstable = Fedora Extras von fedora.us Siehe auch http://fedoratracker.org

Patrice Brockhaus schrieb: Hallo, auch wenn Du so ein instabiles System riskierst? Das liegt daran, dass latest ein symbolischer Link auf 1.92 ist, um schneller die letzte Version zu finden. Das sieht man auch daran, dass im Gegensatz zu den anderen Verzeichnissen latest kursiv geschrieben ist. D.h. der Inhalt von latest und 1.92 ist identisch. Gruß Enrico -- Signaturen-Generator hat einen Fehler. Fehlernummer 666

Patrice Brockhaus schrieb: Aufgrund von Christophs letzten Postings bin ich mir zwar nicht mehr ganz so sicher, aber dachte schon, dass das ein Symlink is, im Mozilla jedenfalls wird dies als einziges Verzeichnis kursiv dargestellt, was meine Symlink-Theorie bestätigen sollte ;-) Gruß Enrico

Am Mo, den 03.05.2004 schrieb Patrice Brockhaus um 18:08: Lieber ein getestetes, funktionierendes foo-1.2-0.rpm von fedora.us als foo-1.2-5.rpm oder foo-1.3-0.rpm von newrpms oder so, die dann nicht funktionieren. Außerdem geht es (zumindest meiner Meinung nach) darum, die Pakete zu testen und so zur Verbesserung beizutragen. Wenn sich aber jeder immer die neusten, ungetesteten Pakete aus Repos Dritter holt, wird das Fedora wohl kaum weiterbringen. 1.92 ist eine feste Version (ist so auf CDs gebrannt worden) "latest" ist immer in Bewegung. Wie Rawhide bei Red Hat. Epoche ist eine Zahl vor der Version: 1:1.6-0 ist größer als 0:1.6-2. Dann wird es wohl ein Paket für FC2 sein? Ist ja auch kein Wunder, wenn von "latest" runterlädst... Kommt drauf an: Als neuestes Pakete wird die testing Version aufgeführt werden, Du kannst aber über Einstellungen -> Experte einen Standart-Release setzen, dann nimmt Synaptic dessen Pakete, wenn's geht. Nein. Extras ist alles, was nicht in Core sein muss und was früher bei fedora.us war. Und noch mehr. Livna war das mit den Lizenzen. Dort findest Du Programme, die beim Übergang vom "Fedora Linux Project" zu Fedora wegen der Lizenzen rausgeflogen sind. Pakete, die aufgrund amerikanischer Exportbestimmungen nicht in den USA gehostet werden dürfen. Da fallen zum Beispiel Verschlüsselungsprogramme drunter, denn würde sich jemand aus einem "Schurkenstaat" sowas herunterladen, wäre das amerikanische Handelsembargo gebrochen. Christoph

On Tue, 4 May 2004 22:04:07 +0200, Patrice Brockhaus wrote: Doch. Oder sollte ich schreiben, noch? Christoph hat insofern Recht, als daß neue fedora.us Pakete erst von mindestens einer weiteren Person "abgesegnet" werden müssen, siehe http://fedora.us/QA - zudem sind die Grenzen zwischen "stable" und "testing" nirgendwo definiert. Oftmals ist es nur erhöhte Vorsicht, die den Packager veranlaßt, ein Paket vorerst in "testing" veröffentlicht sehen zu wollen, obwohl es gut funktioniert. Vielleicht ist er selbst mit dem src.rpm noch nicht zufrieden. Der grundlegende Unterschied zu den Repos Dritter ist einfach, daß dort der jeweilige Packager seine Pakete im stillen Kämmerlein schnürt und ihm dabei niemand auf die Finger schauen oder Einfluß nehmen kann. Fraglich ist ohnehin, wieviel Zeit die jeweilige Person für ein Paket aufwenden kann, wenn sich im Repo Hunderte Pakete befinden und verwaltet werden wollen. Bei Fedora.us ist einsehbar, warum ein Paket schonmal über Hundert Kommentare in bugzilla benötigt, bevor es veröffentlicht wird (Beispiele Thunderbird, Firefox, ALSA) oder was für Fehler gefunden werden, die an das Upstream Projekt gemeldet werden. Eine Pauschalaussage wäre jedoch auch unfair. Denn viele Software läßt sich einfach in ein rpm packen, ohne daß man viel falsch machen kann. [Dennoch kann es recht deutliche Unterschiede im src.rpm geben, die sich auszahlen, wenn Du im Urlaub am Strand liegst und jemand anders ein Bug- oder Security-Fix für Dein Paket erstellt.] Es bringt die Fedora Community nur nicht vorwärts, wenn an mehreren Fronten der Paketentwicklung gleichzeitig "gekämpft" wird und neue Nutzer sich mit Konflikten zwischen vielen Repos konfrontiert sehen. Oder wenn sie mit Bugs in neuester Software kämpfen, ohne für deren Behebung eng mit den Upstream Projekten zusammenzuarbeiten. Das ist vertane Zeit. Auch ist es falsch, von Konkurrenz zu sprechen, da kein Konkurrenzdruck herrscht. Es kommt nicht auf Geschwindigkeit oder die höchsten Versionen an. Es sind ein paar Personen, die bereits vor Planung und Entstehung von fedora.us _und_ vor dem Red Hat Linux Project (später Fedora Project) Zusatzpakete für Red Hat Linux anboten. Wer sein eigenes Projekt liebgewonnen hat, sein Repo als "etabliert" sieht und keine Bedenken hat, Hunderte von Paketen im Alleingang gewissenhaft pflegen zu können, der sieht sein Projekt natürlich von einem offenen Community Projekt bedroht und sich in seinen Freiheiten extrem eingeschränkt. Die Repos Dritter könnten jederzeit auf Fedora.us Extras aufsetzen, Zeit sparen und sich neuen interessanten Paketen widmen, müßten damit aber die Freiheit aufgeben, Pakete in Fedora Core und Extras nach Belieben upgraden zu können und die volle Kontrolle über die eigenen Pakete zu haben. Um Christophs Beispiel deutlicher zu machen: 2:1.0-1 ist größer als 1:2.0-1 Die höchste "Epoch" gewinnt einen Paketversionsvergleich und überstimmt den Vergleich von Paket %version und %release. $ rpm -q --qf "%{epoch}:%{version}-%{release}\n" mozilla 37:1.4.1-18 Sie dient u.a. als Kennzeichnung von Änderungen in ABI/API, als Ausweg für Versionsschemata, die mit RPM inkompatibel ist, also wenn z.B. eine Software folgenden Weg nimmt, 1.0rc1 -> 1.0rc2 -> 1.0 -> 1.0a oder wenn eine Bibliothek aus einem Paket mit Version 2.0 als eigenständiges Paket ausgelagert wird und dort mit einer neuen Version begonnen wird: paket-1.0-1 + libpaket-1.0-1 -> paket-2.0-1, libpaket-0.1-1 Dann soll ja libpaket-0.1-1 ein Update von libpaket-1.0-1 sein. Dazu braucht es mehr als einen reinen Vergleich der Paketversion.

On Thu, 6 May 2004 14:18:41 +0200, Patrice Brockhaus wrote: Sicher, wenn Du mit den rpms vollkommen zufrieden bist, dem Packetersteller ultimativ vertraust und meinst, daß auch die bug- und security-fixes stimmen, warum solltest Du einen Grund zur Beanstandung haben? Ich will die Diskussion auch nicht auf Eventualfälle und sicherheitsrelevante Checks ausweiten. Ich denke jedoch, daß Einzelpersonen einfach nicht skalieren. Noch bieten einige der großen Repos durch die große Zahl an exklusiven rpms nur genügend Blendwerk, um attraktiv zu wirken. "Package request" in fedora.bugzilla.us eintragen und Dich als Tester melden, oder das Paket sogar selbst übernehmen. Wie weißt Du, ob Probleme zur Laufzeit auf gemischte Repositories zurückzuführen sind? Wenn z.B. eine Library mit unterschiedlicher Konfiguration und/oder Optimierungen compiliert wurde und das Laufzeitverhalten negativ beeinflußt. Sorry, ich nutze Yum. freshrpms -> Matthias Saou, atrpms -> Axel Thimm, newrpms -> Rudolf Kastl Die machen das jeweils im Alleingang -- siehe auch ins ChangeLog der rpms (rpm --query --changelog foo) -- bis auf Kommunikationsversuche untereinander, Feedback von Nutzern und das Bestreben, die Konflikte zwischen ihren Repositories in den Griff zu bekommen. Er scheint zumindest sehr viel Freizeit zu haben und darin aufzugehen, rpms für sieben (7!) Distributionen anbieten zu wollen. Bei Tausenden von rpms bleibt ganz sicher keine Zeit zum Testen oder Sichten von Änderungen in Updates, und das Vertrauen in neue Tarballs ist wahrscheinlich unbegrenzt hoch. Siehe ganz unten: http://dag.wieers.com/home-made/apt/ Please note that I invest my time into Red Hat's latest consumer and enterprise products. (Fedora Core 1 and Enterprise Linux 3). Although I try to make sure older releases (RHEL2.1 or RH73) work too they are basicly a free extra of my buildsystem. They may have not been tested as thoroughly. In the future I may end supporting RH62, RH73, RH80 and/or RH90. At the moment I have not made any decisions yet, it's all about how I use my resources. Schau mal in ein src.rpm. Das Source Code Paket (meist .tar.gz oder tar.bz2) wird bevorzugterweise unverändert von den Entwicklern übernommen. Aber die Art, auf die ein Programm konfiguriert, gepatched, ergänzt, compiliert, installiert und in eine Distribution integriert wird, unterscheidet sich manchmal sehr. RPM kann nicht "wissen", daß 1.0a hier neuer ist als 1.0rc2, anstatt eine alpha-Version zu sein: 0.99 -> 1.0a -> 1.0b -> 1.0 (final) Es gibt alternative Ansätze, solche Probleme zu umgehen, ohne eine "Epoch" hochsetzen zu müssen. Es bleibt aber strittig, ob sie auch elegant sind. Damit entfernt man sich vom Versionsschema der Entwickler und sorgt für Verwirrung und Ärgernis bei den Nutzern. Wie ginge es denn weiter mit dem Paket? Wie würde das Paket für Version 0.2 der Bibliothek heißen? Woher weiß der Nutzer, daß es die neue Bibliothek enthält und nicht die alte 1.0 Version? Und was, wenn jemand die alte Lib aufnimmt und weiterpflegt?

On Thu, 6 May 2004 19:36:57 +0200, Andreas Mueller wrote: bugzilla.atrpms.net gibt es m.E. schon recht lange, wurde/wird aber ziemlich geheimgehalten und nicht konsequent von den Repos verlinkt. Zwingend erforderlich, wenn diese "3rd party" Repos skalieren wollen und als Alternative zum Fedora Project auftreten wollen. Quantität statt Qualität. Welches Problem? kde-redhat und OpenOffice.org, AptRpm, eigenwillige Upgrades von Core, diverse andere Konflikte in bugzilla. Kein Geheimnis, wenn Du in Foren mitliest. Das ist der Unterschied. Ich spreche nicht aus eigener Erfahrung. Du aber schließt offenbar von Deiner Erfahrung darauf, daß andere Nutzer auch keine Probleme hätten. Deswegen propagiere ich Fedora Extras (derzeit halt noch fedora.us), anstatt 3rd party repositories. Die sind stabiler und sicherer? ;)

On Fri, 7 May 2004 19:24:46 +0200, Andreas Mueller wrote: Weil sie bisher doch auch einfach Pakete in Fedora Core upgraden, ohne den Usern die Wahl zu lassen dies zu tun oder nicht, und weil sie voraussichtlich auch mit Fedora Extras überschneidende Pakete anbieten werden. Mir ist nicht klar, wie Du auf solche Verschwörungstheorien kommst. Unterstelle mir doch bitte keine Feindseeligkeit. ;) Natürlich. Aber wer nicht in Abhängigkeitsfallen tappen möchte oder als Newbie nicht den Einblick in die unterschiedlichen Entwicklungsmodelle hat, fragt um Rat und möchte nicht ins offene Messer laufen. Präventiver Community Support ist einfacher als Schadensregulierung. Warum nicht? Einträge in bugzilla und diverse Usererfahrungen widersprechen dem. Rex Dieter würde das nicht leugnen. Wenn etwas nachträglich in einem "stable" repository behoben wird, dann ändert das nichts daran, daß so ein Konflikt vorgekommen ist. Das jüngste KDE Upgrade hatte ja sogar einiges übel zerschossen. Das ist und bleibt ein Konflikt. Ganz neu in bugzilla ist ein Konflikt mit Yum. Was rechtfertigt einen Versionssprung von in mehreren Test Releases (Red Hat Linux 9.0.93, Fedora Core 0.94, Fedora Core 0.95) getesteter Software auf ein ganz neues, nicht entsprechend gestestes Release? Und diese Frage geht auch um Core Komponenten, Bibliotheken z.B., oder gar den Linux kernel. Ja nun, wer soll sich denn nach wem richten in Bezug auf Paketnamen, Paketinhalten, "virtual provides" und anderen Dingen? Das bedeutet aber nicht, daß man die Zielgruppe des "Fedora Project" instabiler und ungetesteter Software aussetzen muß. Aus diesem Blickwinkel ist es nur positiv zu sehen, wenn die Fedora Community sich um Qualitätssicherung kümmert [und gegebenfalls Fedora Extras sogar release-basiert an Fedora Core koppelt].

On Fri, 7 May 2004 21:31:03 +0200, Andreas Mueller wrote: Falsch? Oben schrieb ich "Alternative zum Fedora Project". Mit der Terminologie des Fedora Projects nennt sich das, was Du beschreibst, "Fedora Alternatives". Als Glaubensvertreter von freshrpms & Co steht es Dir frei, auf vermeintliche Risiken von Fedora Extras (noch fedora.us) hinzuweisen. Ich sehe es nicht als mein Betätigungsfeld, mich an jeden, der auf freshrpms verweist, mit einem Nachruf heranzuhängen. In diesem Thread wurde jedoch eine Frage aufgeworfen. http://lists.freshrpms.net/pipermail/freshrpms-list/2004-April/008722.html Dateikonflikte mit OpenOffice.org Paketen aus Fedora Core lassen sich nicht lösen, indem man weitere Extrapakete hinzunimmt. Sie lassen sich nur lösen, indem die entsprechenden Dateien herausgenommen oder dupliziert werden. Nein, er "fixed" seine Pakete. ;) Was ist das hier? http://atrpms.net/dist/fc1/kernel/ "This is the RedHat kernel with some additional patches."

On Fri, May 07, 2004 at 09:59:22PM +0200, Michael Schwendt wrote: Und wo genau liegt nochmal Dein Problem? Außer natürlich, daß alles, was nicht fedora.us ist, automatisch schlecht ist? ;) Leider sind einige der Patches nicht für die derzeitige strategische Ausrichtung von Red Hat/Fedora geeignet, so daß sie nicht ins Programm aufgenommen werden (können). Das mindert aber bei weitem nicht den Mehrwert, den diese mit sich bringen. Teilweise sind einige der Patches, z.B. neulich die smp Hänger, endlich in den Red Hat kernel aufgenommen worden. Gerade der kernel von ATrpms gehört zu den Dauerrennern, wenn man sinnvolle Server (xfs/lm_sensors/autofs/natt-ipsec) oder Multimedia (v4l2) verwenden will. PlanetCCRMA baut im übrigen auch eigene kernels, die exzellente Latenzzeiten wiedergeben, die insbesondere für Audioanwendungen geeignet sind. Die CCRMA kernel kann ich für Desktoprechner nur empfehlen! Also bitte keine unnötige Panikmache und Hetzerei. Es sind wenige Leute innerhalb von fedora.us, die noch eine Mauer aufrechthalten wollen. Gruß, Axel. -- Axel.Thimm at ATrpms.net

Am Di, den 18.05.2004 schrieb Axel Thimm um 01:32: Ja, das ist mir auch irgendwie abhanden gekommen :-) Was mir bei fedora.us und livna.org gefällt ist, dass die packages aus beiden mit relativ wenig zusätzlichen Eingriffen in das Grundsystem auskommen. Installieren sich fast so, wie zusätzliche CDs der Distribution. Bei ATrpms und auch freshrpms werden manchmal selbst für eigentlich recht simple Sachen zusätzliche "Umbauten" mit durchgeführt. Z.B. bei xine von freshrpms wurde bei Core 1 gleich Alsa mit eingebaut. Bei livna ging es auch ohne, nur mit OSS. Bei ARTrpms und MadWifi mußte auch gleich noch einiges mehr mit installiert werden. Bei beiden letzteren wird offensichtlich eine eigene "Philosophie" mit verfolgt, die von der Fedoras abweicht oder sich zumindest unterscheidet. Was das für eine Philosophie im Detail ist und woraus sie sich begründet, wird nicht so recht deutlich - oder mir zumindest nicht. ATrpms hat ja schon sehr viel Dokumentation zu den Paketen. Vielleicht wäre es sinnvoll, noch ein paar Sätze einzufügen, die den Verwendungszusammenhang oder eben gerade den intendierten "Mehrwert" explizieren. Gruß Peter

Hi, On Fri, May 07, 2004 at 09:31:03PM +0200, Andreas Mueller wrote: um welches Problem genau geht es, und wieso habe ich es noch nicht gelöst? :) Gruß, Axel. -- Axel.Thimm at ATrpms.net

On Tue, 18 May 2004 02:16:27 +0200, Axel Thimm wrote: Nach so einem Aufruf erwartete ich eigentlich keine Feindseeligkeiten. "shadow-utils" wird nirgendwo von fedora.us _ersetzt_. Wo finde ich in fedora.us "libsafe"? Mit "Fedora Extras" meine ich das zukünftige offizielle Fedora Extras, nicht Pakete in fedora.us. Zu behaupten, Pakete seien "geklont", ist ein Vorwurf, den die hauptaktiven Packager entkräften würden, wenn sie ihn hörten. Entspricht nicht der Wahrheit. Woher nimmst Du das? Mozilla ist ein _Upgrade_, das eine existierende ältere gut getestete Version einfach ersetzt, wenn der User das entpsprechende Repository wählt. Kernel Module sind optionale add-ons. Extras.

Am Di, den 18.05.2004 schrieb Michael Schwendt um 2:32: Dann will ich mich jetzt noch versuchen auf beiden Seiten unbeliebt zu machen. ;-) [...] Warum das Rad immer wieder neu erfinden? IMHO wollen wir es den Usern doch einfach machen. Und das geht IMHO am einfachsten wenn wir nicht die gleichen Pakete an zig verschiedenen Stellen mehrfach lagern und von zig verschiedenen Leuten pflegen -- Verschwendung von man-power IMHO und gerade dadurch kommt es AFAICS auch manchmal zu kleineren (oder größeren) Problemen. Um dies zu lösen eignet sich fedora.us ja als "offizieller" Fedora-Extra Vorläufer IMHO derzeit am besten (auch wenn Axel und die anderen eigentlich vorher da waren). Auch wenn die Hürden, da Pakete reinzubekommen, relativ hoch liegen(IMHO manchmal ein klein wenig zu hoch, aber das ist ein anderes Thema). So, jetzt hab ich mich bei Axel unbeliebt gemacht, jetzt bei Michael ;-) [...] Hier sehe ich derzeit etwas das Axel und andere bieten und was fedora.us/Fedora@redhat fehlt (und haben sollte). Es gibt immer Leute die wollen aus guten(*) oder (weit häufiger) schlechten Gründen neue Versionen möchten. Einen Kernel mit neueren Treibern|Low-Latency-Patches oder gar einen Vanilla-Kernel. Oder die aktuellste Mozilla/Gnome/KDE-Version. Oder was auch immer. Gut, einige von denen können (wenn Sie mutig sind) dafür auch rawhide nutzen, aber ich will nicht täglich X MB runterladen nur wegen einem kleinen Fix irgendwo der mich meist nicht betrifft. Oder ich muss SRPMS mit der richtigen GLIBC und dem passenden Compiler umständlich manuell neu übersetzen (tritt zwar nur manchmal auf, aber tritt auf). Alternativ kann man sich vieles auch an zig verschiedenen Stellen zusammensuchen -- auf people.redhat.com (kernel, gnome, evolution, ...), download.kde.org (kde, aber, AFAIK auch von someone@redhat kompiliert), bei Axel, Dag oder Freshrpms. Alles reichlich kompliziert. Daher sollte fedora hier IMHO selbst was tun und diese ganzen quellen zusammenführen. Das könnte als eigene unstable Repository (mit wenig/kaum QA) innerhalb von fedora.us/fedora core mitlaufen. So weit getrennt das ich wenn ich ein neues Gnome einspiele nicht gleich gezwungen werde, einen neuen Kernel einzuspielen. Oder andersrum. So wie möglicherweise mit mit Mozilla passiert sobald ich Axel's repository wegen eines anderen Programms in meiner yum.conf hinzufüge (Warning: vielleicht kann apt/Synaptic das besser -- keine Ahnung; Und, ja, ich weiß das man bei yum bestimmte Pakete aus/einschließen kann -- aber das ist nicht so einfach wenn neue Pakete auftauchen). (*) Ein wirklich gutes IMHO Beispiel ist IMHO ein Bug-Report der bei Red Hat (aus welchen gründen auch immer) nicht bearbeitet wird. Dann möchte ich gern relativ einfach die letzte (möglichst unmodifizierte, d.h. ohne spezielle RH-Patches) Upstream Version einspielen. Wenn der Fehler da dann auch auftritt kann ich das auch Upstream melden -- wenn ich bespielsweise einen Fehler mit dem Fedora Kernel auf der LKML melde werde ich (zu recht) ausgelacht. Die von mir häufiger angebrachte Hardware-Unterstützung ist hier auch ein Beispiel. Sane kam gerade (kurz nach Freeze) mit einer neuen Version raus. Benötige ich die weil erst diese Version meinen Super-Duper-Scanner unterstützt muss ich jetzt ein halbes Jahr bis zur nächsten Core-Version warten wenn ich zu dumm bin, es mir selbst zu kompilieren oder irgendwo in den weiten des WWW ein für FC2 passendes RPM zu finden... CU thl

Am Di, den 18.05.2004 schrieb Axel Thimm um 20:36: [...] Da bin ich dann ja mal doch gespannt. Mal gucken wie lange es noch dauert mit dem offiziellen "fedora extras@redhat" und wie es sich dann nebenher entwickelt Aber die Stimmung wurde gelockert ;-) Wenn sich irgendwann die Gelegenheit bietet werde ich mich dran erinnern ;-)) Soll ich jetzt fragen wo? Nein, das wäre gemein. Aber, wie gesagt, bei dir und den anderen bekomme ich (mit yum) schnell einen neuen Kernel oder andere Updates die ich gar nicht will. Weil mich (und IMHO viele andere) die Sucherei in X-verschiedenen repros an Y verschiedenen Stellen nervt. Ich bin halt eher Anhänger der "wenige große repros die sich möglichst nicht überschneiden" Lösung. Zudem waren meine Worte auch zusammenführen und nicht "neu erfinden" ;-) Und die Kritik ging in Richtung fedora.us/fc. CU thl

Am Di, den 18.05.2004 schrieb Axel Thimm um 21:37: Als Globalisierungsgegner mags du recht haben. Aber ich war (in der vorherigen Wohnung) das Gegenbeispiel: Kein Auto, nur Fahhrad, ein Suppermarkt in der näche, zwei/drei andere doppelt so weit (2 km) weg, Aldi&Co 3km. Aus Bequemlichkeit kauft man doch fast immer nur bei einem Suppermarkt und geht nie zum Aldi Ich werde es in erwägung ziehen. Jetzt wollte ichs gerade ausprobieren und nachgucken und habe meinem frischen FC2 Update (livna und fedora.us auch upgedated) in der yum.conf [atrpmsstable] name=temp baseurl=http://apt.physik.fu-berlin.de/fedora/2/en/i386/at-stable/RPMS.at-stable/ Hinzgefügt. Schwups: Resolving dependencies .Package transcode needs libfame-0.9.so.0, this is not available. Package xine-lib needs libfame-0.9.so.0, this is not available. Package transcode needs liba52.so.0, this is not available. Sowas dummes... Schwups, du bist wieder raus. BTW, ändere doch mal auf http://atrpms.net/install.html das yum-Beispiel von [atrpmsstable] name=Red Hat Linux 9 ATrpms stable baseurl=http://apt.physik.fu-berlin.de/redhat/9/en/i386/at-stable in [atrpmsstable] name=Fedora Core $releasever ATrpms stable baseurl=http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-stable/ CU thl

Am Di, den 18.05.2004 schrieb Axel Thimm um 22:42: Sorry, war keine Absicht. Hatte einfach nur den alten auskommentierten Eintrag angepasst -- die Verzeichnisse waren ja ungefähr da wo sie zu erwarten waren. Wieder eins dieser Probleme wenn ich mich bei X verschiedenen Repros auf dem laufenden halten muss wann diese nun offiziell "released" sind. Zudem: Warst du es nicht der fedora.us kritisierte weil Warren als RH Mitarbeiter in irgendeinem AFAIK *nicht offiziellen verzeichneten* Verzeichnis Dateien abgelegt hatte, die Sachen aus Core ersetzten? CU thl

Am Mi, den 19.05.2004 schrieb Axel Thimm um 17:19: Gut möglich. Naja, man *könnte* es auch wie folgt sehen: ATrpms (oder eine beliebige andere Repro) hat sich entschlossen für fedora (vormals rhl) Pakete zu bauen. Zu Fedora gehört seit dem es Fedora heißt *eigentlich* (hier kommt es auch auf die persönliche Sichtweise an) auch fedora.us. Daher sollte eine Repro Kompatibilität dazu waren und nicht bewusst teile von Extras (fedora.us) oder (viel schlimmer) Core ersetzen. Oder wenn doch, dann sollte dies in einer speziellen Repro geschehen wo hier vor ausdrücklich gewarnt wird. [...] Was ja auch eine Idee wäre. Klingt vernünftig, ich bin mir aber nicht sicher ob das wirklich so gehen kann. Zudem verweise ich gerne auf die oben beschriebene Sichtweise. Danach müsste sich 3rd party Repros nach core und fedora.us richten. Was natürlich keineswegs heißt das fedora.us begründete Bugreports ignorieren sollte! Sorry, hab nochmal nachgeguckt, mein Fehler, ziehe alles zurück. Mea culpa. CU thl

Am Di, den 18.05.2004 schrieb Axel Thimm um 20:36: Hi Axel! Am besten wir laden Dag ein, und zetteln eine Diskussion über Versions und Paketnamen an, dann ist hier wenigstens mal was los. ;-) SCNR Grüße und Danke für Deine ganze Repo-Arbeit! André

On Tue, 18 May 2004 20:36:00 +0200, Axel Thimm wrote: Bzw. sind gar nicht erst eingetreten. Aktivität auf einer Mailing-Liste ist noch kein "Eintritt". Ack. Paketentwicklung sollte auf Mailing-Listen stattfinden und von "development" repositories gestützt werden, anstatt in Bugzilla verlagert zu werden. Weit über 100 "bugzilla comments" zu einem Paket, das in die QA queue gestellt wurde, sind overkill und der Entwicklung nur bedingt förderlich. Unmachbar, da nicht nur der am weitesten rechts stehende Teil von %release Versionen in EVR Vergleiche einfließt, sondern schonmal gar nicht akzeptiert wurde, daß fedora.us alle Extrapakete in einem zentralen Repository anbieten wollte (um Splitterung zu vermeiden und Zugang zu Extras zu vereinfachen), ohne von weniger offenen Repositories abhängig zu sein. Bereits Kleinigkeiten, wie die verwendete Top-Level Domain ".us" führten ja zu Streitigkeiten und Mißgunst. Nichts, was sich nicht korrigieren ließe, wenn es notwendig wäre. "Es gibt nur uns" ist Unsinn. Laß doch bitte sowas, Axel. Passendes Zitat dazu: "Axel likes to badmouth me, and he's done a good job today by trying to isolate me." - (Dag Wieers) Fakt ist, in das Konzept von fedora.us passen keine Abhängigkeiten auf externe Repositories. Wer meine Kommentare -- und ich war nicht von Beginn an dabei -- kennt, erinnert sich noch daran, daß ich nach einer Lösung suchte, wie man z.B. Matthias Saous Pakete hätte integrieren können. Aber die Fronten waren bereits zu verhärtet und es schien kein Interesse an einem gemeinsamen Projekt. Ist mir schleierhaft, wie das wirklich "sauber" zu lösen sein soll, wenn verschiedene Versionen von Paketen in unterschiedlichen Repositories existieren, unterschiedlich konfiguriert und compiliert sind, unterschiedliche Inhalte haben und sich gegenseitig upgraden.

On Tue, May 18, 2004 at 09:45:30PM +0200, Michael Schwendt wrote: In den Ur-Fedora Projekt sind wir alle eingetreten und trugen in Form von Diskussionen und Spezifikationen über mehrere Monate bei. Nach dem Austritt der Repos blieben halt die damaligen Leute übrig. Es wurde keine produktive Arbeit (Paketbauen) geleistet, aber ein Projekt startet nicht erst bei der Produktion ... das ist genau der Wortlaut der alten fedora.us Garde, die man heute nicht mehr gebrauchen kann. Wenn Du von verhärteten Fronten sprichst, so sollte es Dir Gewiss sein, daß Du sie verhärtest. Hörensagen! Bitte zitieren, weil ATrpms demnächst genau das machen wird ... Du pauschalisierst und wirfst alle in einen Topf. Hierrüber hatten sich Matthias aufgeregt, sogar einige damalige fedora.us Mitglieder. Du kannst nicht einfach nur zwischen fedora.us und "den Anderen" unterscheiden, das ganze ist weitaus feinkörniger. Obwohl ich selbst die Argumentation über die Wahl von *.us zugegebenermaßen als scheinheilig empfand ("gab nicht anderes" ...), war es mir in Anbetracht echter Probleme ziemlich unwichtig, ob es fedora.us, oder myrepo200.cc heißen sollte. Nun dann, ich will sehen, wie jemand ein einziges Paket von livna nach fedora.us gebracht werden könnte, Lizenzproblematik beiseite. Das Problem ist nun evident, und trotz des "Es kann nur einen geben", gibt es doch inzwischen zwei ... ;) Vollkommen off-topic, soll ich auch die Meinung Deiner Kindergartenlehrering über Dich zitieren? Frag das nächste Mal die Meinung meiner Schwiegermutter, die wird vielleicht passender sein ... Das ist aber wieder scheinheilig. Zum einen gehörts Du zu denjenigen, die die Fronten verhärten. Ich war (negativ) über Deine Propaganda hier überrascht, obwohl ich schon öfter das Vergnügen hatte. Zum anderen kann es kein gemeinsames Projekt geben, wenn sich ein Partner isoliert, so sehr der andere die hand ausstreckt. Wo ein Wille ist, ist auch ein Weg. Sobald sich fedora.us zu einer entgültigen Öffnung und Streichung der alten Police schreitet, heißt das auch Kompatibilität _von beiden_ Seiten zu achten. Es klappt (mit den gewöhnlichen OSI Reibereien) mit ca 2000 Paketen, da werden die zusätzlichen 500? von fedora.us ebenso mitgehandhabt werden. -- Axel.Thimm at ATrpms.net

On Tue, May 18, 2004 at 11:00:46PM +0200, Michael Schwendt wrote: Da mußt Du von einem anderen Projekt sprechen, von Anfang an wurde freshrpms als Basisplattform vorgeschlagen, die einige ohne besonder Gründe nicht akzeptieren wollten, weil sie lieber ein neues Repo aufmachen wollten. Darf ich das in meine Signatur aufnehmen? :) Dann bitte keine Unwahrheiten verbreiten ... -- Axel.Thimm at ATrpms.net

On Tue, May 18, 2004 at 11:13:48PM +0200, Axel Thimm wrote: On Tue, May 18, 2004 at 11:41:29PM +0200, Michael Schwendt wrote: Ist es schon Freitag Nacht? Ich soll etwas zitieren, was nur in Deiner Phantasie existiert? Wenn Du irgendwas behauptest, mußt Du das auch belegen können, sonst könnte man auf den Gedanken kommen Du verschleierst zugunsten Deiner Propaganda bewußt die Tatsachen. Also ich glaube ich hatte genug davon für heute ... -- Axel.Thimm at ATrpms.net

On Wed, May 19, 2004 at 12:02:52AM +0200, Axel Thimm wrote: On Wed, May 19, 2004 at 12:41:25AM +0200, Michael Schwendt wrote: Ich hoffe Dein killfile ist Listenübergreifend. Bitte halte Dich auch daran! :) -- Axel.Thimm at ATrpms.net

On Wed, 19 May 2004 22:34:52 +0200, Andreas Pfaffeneder wrote: Wer sich einlesen möchte, das Archiv existiert noch und als Mailbox downloadbar: http://www.fedora.us/pipermail/fedora-devel/ Erinnerungsgemäß relevant bis spätestens April/Mai 2003.

On Tue, 18 May 2004 20:04:47 +0200, Thorsten Leemhuis wrote: Hat sich in Bezug auf ALSA aber gelohnt, wie ich finde. Zumindest sind die Pakete besser und vollständiger, als die in einigen anderen Repositories. Was Updates betrifft, so sind Policy Änderungen geplant, nach denen "trusted developers" weniger Hürden zu nehmen haben und Updates vereinfacht werden. Schön. Aber auch solche Pakete muß überhaupt erstmal jemand erstellen. Und als was würdest Du die dann deklarieren, damit sie auch jemand antestet und nicht fürchtet, alle Daten zu verlieren? Lohnt sich der Aufwand parallel zu Fedora Core Development? Oder ziehen sich die Geeks nicht die tarballs ohnehin direkt? Community Project => wo ist der Patch? Wie auch Nutzer von anderen Distributionen, insbesondere SuSE Linux mit einer vielfach höheren Zahl an kernel patches. Die Zahl der kernel patches wurde in Fedora Core 1 und nochmals in Fedora Core 2 drastisch reduziert. Solche Upgrades passen wunderbar in das "Fedora Alternatives" Konzept.

On Tue, 18 May 2004 02:16:27 +0200, Axel Thimm wrote: Hab mich entschlossen, noch etwas weiter zu suchen. Beide Pakete befinden sich im vollkommen optionalen "patches" repository, das sich nichtmal innerhalb des Hauptverzeichnisbaums befindet, sondern versteckt weit oberhalb - http://download.fedora.us/patches - und nicht voreingestellt ist. Also rücksichtsvoll ausgelagert.

Patrice Brockhaus wrote: Nein. Die "großen" 3rd Party Repos (dag, freshrpms, newrpms, ATrpms) stellen ähnliche Pakete wie Fedora Extras bereit. Wenn man also eine gemischte Konfiguration mit fedora.us (= das einzige zur Zeit existierende Fedora Extra) und den 3rd Party Repos fährt, kommen sich diese Pakete aufgrund von Abhängigkeitsproblemen in die Quere. Beispiel: Paket A hängt von B ab. A stammt aus Fedora Extras, B ist sowohl in Extras als auch in den 3rd Party Repos enthalten. Wenn B jetzt in den 3rd Party Repos in einer aktuelleren Version vorliegt, würde apt/yum/up2date natürlich diese installieren. Wenn aber B in Extras andere Dateien enthält als B in den 3rd Party Repos, kann es sehr leicht zu Problemen kommen. Legacy: Bugfixes und Updates für alte Versionen von Red Hat Linux und Fedora Core, die von Red Hat nicht mehr unterstützt werden, zur Zeit gibt es Legacy-RPMS für RH 7.2, 7.3, 8.0, 9. Wenn Fedora Core 1 ausläuft (geplant sind ca. 3 Monate nach dem Release von FC2), wird es auch dafür Legacy-Support geben. Alternatives: Pakete, die Software aus Fedora Core ersetzen. Wie das genau aussieht, kann ich Dir nicht sagen, mir ist kein existierendes Fedora Alternatives bekannt. Details siehe: http://fedora.redhat.com/participate/terminology.html Das habe ich nicht behauptet. Es hängt aber von den Betreibern von Fedora Legacy ab, ob und wann Sicherheitsupdates (und Bugfixes) zur Verfügung gestellt werden. Insbesondere beim Kernel dürfte das schwierig werden, denn Red Hat hat bis jetzt viele Bugfixes/Patches aus neueren Versionen auf den verwendeten (alten) Kernel zurückportiert, das setzt schon einiges an Know How und Zeit voraus. Außerdem gibt es noch ein Problem: einige (viele? alle?) Sicherheitsprobleme werden zuerst den Herstellern der Software gemeldet, bevor sie veröffentlicht werden, damit diese genug Zeit zum Patchen haben. Es stellt sich daher die Frage, ob Fedora Legacy Zugriff auf diese Informationen hat. (Weiß da jemand genaueres?) Deshalb würde ich auf kritischen Systemen, bei denen es insbesondere auf Sicherheit ankommt, eher RHEL (auch wegen der längeren Lebensdauer) verwenden. Grüße, Andreas.

Am Di, den 04.05.2004 schrieb Patrice Brockhaus um 22:04: (Dazu ist glaube ich schon genug geschrieben worden und ich stimme mit dem, was gesagt wurde weitestgehend überein.) Ein klares jein! Sicherlich haben alle Repos ihre Berechtigung: Der eine macht auf Multimedia (planet ccrma), der andere auf KDE (kde-redhat oder dries) und der dritte auf gnome (nyquist). Ein ganz anderer hat den Anspruch, immer die neusten RPMs zu haben. Andererseits würde ich gerne mehr Pakete an zentraler Stelle mit einheitlichem Qualitätsstandard, zentralem Bugzilla, Mailingliste etc sehen. Was nützt es, wann man 5 verschiedene ALSA Pakete hat, von denen nur 2 oder 3 was taugen? keine Infos angegeben, sollte nicht sein. das ist IMO fedora.us oder livna.org. Bei mir klappt das wunderbar: Ich habe: ignorieren, NyQuist, testing, stable, Fedora Compatible Packages, Fedora Linux Freshrpms, Unknown, ATrpms. (manchmal auch planetccrma oder unstable, wenn es aktiviert ist.) Stable habe ich als Standard (habe aber auch ne Menge testing oder3rd Party), wird als neustes Paket angezeigt (die anderen erscheinen bei Experte) und auch installiert, wenn ich nichts anderes auswähle. Manchmal gibt es Probleme: Als ich gstreamer von 0.63 fedora/livna auf 0.64 freshrpms aktualisieren wollte, ist er doch sehr durcheinander gekommen, weil viele Programme darauf aufsetzen. Einmal freshrpms als Standard gesetzt, schon lief es (fast) problemlos. Welche Version vom apt/synaptic verwendest Du? $ rpm -qa *apt* synaptic-0.48.1-0.fdr.3.1 apt-0.5.15cnc6-0.fdr.11.1 Ja. Das was Nachfolger von Red Hat 9 ist, vom Steering Committee verwaltet wird und nicht Extras oder Alternatives ist (wurde ja schon erläutert). Grüße zurück Christoph