Fragen zu Synaptic

[Thorsten Leemhuis]

Am Di, den 18.05.2004 schrieb Michael Schwendt um 2:32:
> On Tue, 18 May 2004 02:16:27 +0200, Axel Thimm wrote:
> 
> > Also meine Herren, bitte!
> 
> Nach so einem Aufruf erwartete ich eigentlich keine Feindseligkeiten.

Dann will ich mich jetzt noch versuchen auf beiden Seiten unbeliebt zu
machen. ;-)

[...]

> > > 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?

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 ;-)

> > > > 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.

[...]
 
> > Viel schlimmer noch! mozilla Upgrades werden verdammt, während man in
> > aller Ruhe kernel module beliebig hinzufügen können soll?
> 
> 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.

Hier sehe ich derzeit etwas das Axel und andere bieten und was
fedora.us/Fedora at 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 at 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