7:16 p.m.
Also meine Herren, bitte!
Kaum trage ich mich in diese Liste ein, schon jagt mich das Gespenst
von Michael wieder. ;)
Gut, daß man wenigstens die Chance bekommt die Sachen wieder ins
rechte Licht zu rücken ...
On Thu, May 06, 2004 at 08:58:44PM +0200, Michael Schwendt wrote:
On Thu, 6 May 2004 19:36:57 +0200, Andreas Mueller wrote:
> Mittlerweile gibt es ein gemeinsames Bugzilla,
bugzilla.atrpms.net gibt es m.E. schon recht lange, wurde/wird aber
ziemlich geheimgehalten und nicht konsequent von den Repos verlinkt.
Natürlich, wenn das nicht eine Verschwörungstheorie ist. Wozu sollte
eine Geheimhaltung dienen? Etwa um nicht zuviele Bugs gemeldet zu
bekommen? ;)
Ja, es stimmt, die meisten Repos haben keine gute PR, sie konzentieren
sich auf's Wesentliche, nämlich Pakete schnüren. Wir brauchen wohl
auch jemanden wie Michael, der die Foren und Mailinglisten unsicher
macht ;)
> ATrpms wird demnächst auch für andere Packager offen sein
Zwingend erforderlich, wenn diese "3rd party" Repos skalieren wollen
und als Alternative zum Fedora Project auftreten wollen.
Wie Bitte? Alternative? Schöne subtile Ausgrenzung. Jedes "3rd Party"
Repo versteht sich als Teil vom Fedora Projekt.
> > Noch bieten einige der großen Repos durch die große Zahl
an
> > exklusiven rpms nur genügend Blendwerk, um attraktiv zu wirken.
>
> Welches Blendwerk denn?
Quantität statt Qualität.
Wow, das geht unter die Gürtellinie. Schön dahergesagt, und sicher
wirst Du bei Nachfrage sogar ein Paket von den ca 1500 Paketen der
freien Repos finden können, welches qualitativ schlechter ist als ein
anderes.
Für die Qualität der freien Repos spricht die Userschaft.
On Fri, May 07, 2004 at 08:19:07PM +0200, Michael Schwendt wrote:
Weil sie bisher doch auch einfach Pakete in Fedora Core upgraden,
Du meinst Pakete, die ziemlich systemnahe liegen und somit die
Stabilitätsgarantie des Vendors erlöschen würden? Also das Ersetzen
von Paketen wie shadow-utils und libsafe? Wie z.B. fedora.us es macht?
voraussichtlich auch mit Fedora Extras überschneidende Pakete
anbieten werden.
Du meinst die Pakete, die ursprünglich aus freshrpms stammen? Soll
also freshrpms z.B. nachdem die Pakete nach fedora.us geklont wurden,
einfach die Hände in den Schoß legen?
> Das Problem, nicht akzeptieren zu wollen, dass es andere Repos
mit
> völlig anderen Herangehensweisen als fedora.us gibt, die aber deswegen
> nicht automatisch schlechter als fedora.us sind.
Mir ist nicht klar, wie Du auf solche Verschwörungstheorien kommst.
Unterstelle mir doch bitte keine Feindseeligkeit. ;)
Genau, bitte laß mir diesen Vorzug: Michael, Du bist allem, was nicht
fedora.us dranstehen hat, wirklich sehr feindselig gegenüber. Das hilft
wirklich nicht der Sache.
Während der Großteil (!) der Entwickler von fedora.us von dem alten
Credo "Es kann nur einen geben" wegkommen will, und die Zusammenarbeit
mit den anderen Repos begrüßen, behindern sture Haltungen eine weitere
Öffnung.
Es geht hier nicht um einen Schönheitspreis, oder um einen
Blumentopfgewinn, sondern um ein vernünftiges System zum laufen zu
bekommen.
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.
Das könnte fast so klingen, als würdest Du von fedora.us abraten?
Wenn etwas nachträglich in einem "stable" repository
behoben wird, dann
ändert das nichts daran, daß so ein Konflikt vorgekommen ist.
Stimmt, und was lernen wir daraus?
> Was ich trotzdem nicht verstehe: Warum sträubst du dich gegen
> "eigenwillige Upgrades" von Paketen? Nirgendwo steht, dass das
> nicht erlaubt wäre (im Gegensatz zu Fedora Extras), und ich habe
> beispielsweise kein Problem damit, Mozilla 1.6 zu nutzen.
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.
Na ja, mit der Logik, was rechtfertigt überhaupt zusätzliche Pakete zu
einer getesteten Distribution hinzuzufügen? Destabilisiert nicht jedes
neue Paket potentiell das System?
Viel schlimmer noch! mozilla Upgrades werden verdammt, während man in
aller Ruhe kernel module beliebig hinzufügen können soll?
Von Seiten der Stabilität würde man an erster Stelle kernel module
verbieten, dann erst an Paketupgrades denken ...
Solange man kernel module zuäßt, ist das Argument der "Paketupgrades
sind böse" ziemlich scheinheilig.
Ja nun, wer soll sich denn nach wem richten in Bezug auf Paketnamen,
Paketinhalten, "virtual provides" und anderen Dingen?
Das ist eine andere Sache. Derzeit ist Red Hat/Fedora schon fast die
einzige Distribution, die keine sauberen Richtlinien hierzu hat. Das
wird immer wieder andiskutiert und versandet ins Desinteresse. Denn es
_muß_ mind. Red Hat mit irgendeinem Standard mitmachen, sonst gibt es
nie eine Konvergenz.
Aus diesem Blickwinkel ist es nur positiv zu sehen, wenn die Fedora
Community sich um Qualitätssicherung kümmert
Genau, und das passiert bei den meisten Repos, Qualitätssicherung ist
eben nicht nur meterweise Diskussionen in bugzilla aufzunehmen.
--
Axel.Thimm at ATrpms.net