Fragen zu Synaptic

[Michael Schwendt]

On Thu, 6 May 2004 14:18:41 +0200, Patrice Brockhaus wrote:

> > 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. 
> 
> Was mir ziemlich Wurscht sein kann, solange die rpms funktionieren 

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.

> und wenn es das Paket bei Fedora nun mal nicht gibt.

"Package request" in fedora.bugzilla.us eintragen und Dich als Tester
melden, oder das Paket sogar selbst übernehmen.

> Ärgerlich wird es natürlich, 
> sollte ich irgendwann Probleme mit den Abhängigkeiten bekommen.

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.

> Leider kann 
> ich ja in Synaptic nicht einstellen, das die rpms von fedora.us auch bei 
> niedrigerer Version bevorzugt installiert werden sollen. Kennst du die genaue 
> Bedeutung der Karte: "Einstellungen/Experte" unter Synaptic? Leider finde ich 
> keine Doku zu dem Programm.

Sorry, ich nutze Yum.

> Ich wusste nicht, dass diese Repos nur von jeweils 
> einer Person betrieben werden. Ist das tatsächlich so?

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.

> Woher nimmt z.B. Dag 
> Weers seine Pakete? Er betätigt sich wohl eher als (um-)packer denn als 
> Programmierer?

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.

> > 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.
> 
> Bedeutet das, dass jedes Paket für Fedora speziell umgecodet wird? Der 
> Unterschied der Distributionen liegt doch auschließlich in der 
> Verzeichnisstruktur und Versionen einiger Bibliotheken - wie z.B. glibc.   
> Werden diese Eigenheiten nicht beim Kompilieren berücksichtigt?

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.

> >   1.0rc1 -> 1.0rc2 -> 1.0 -> 1.0a
> 
> Warum die Pakete nicht eben genau so bezeichnen? Weil rpm das nicht auflösen 
> kann?

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.

> > 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.
> 
> Warum das ausgelagerte Paket nicht einfach "libpaket-1.0-2" nennen?

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?