Fragen zu Synaptic

[Michael Schwendt]

On Tue, 4 May 2004 22:04:07 +0200, Patrice Brockhaus wrote:

> Am Montag, 3. Mai 2004 19:04 schrieb Christoph Wickert:
> 
> > 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.
> 
> Na die sind doch nicht weniger getestet als neue (testing-) rpms aus dem 
> Fedora-repo.

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

> Konkurrenz belebt das Geschäft!

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.

> > > > Vielleicht hat Mozilla-1.6-0 aus Dags repo aber auch eine höhere
> > > > "Epoch" und wird deshalb als neuer behandelt.
> > >
> > > Was meinst du mit "Epoche"?
> >
> > Epoche ist eine Zahl vor der Version: 1:1.6-0 ist größer als 0:1.6-2.
> 
> Und was besagt diese Zahl? 

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.