fedora.us was Re: sound-probz mit arts und oss

[Michael Schwendt]

On Thu, 29 Jan 2004 17:04:18 +0100, Ronny Buchmann wrote:

> Mir ist es egal ob in einem spec file viel oder wenig Arbeit steckt.

Das hat mit "viel" oder "wenig Arbeit" nichts zu tun, sondern mit
Korrektheit des spec Skripts und damit verbundenem Wartungsaufwand. Ich
möchte nicht ein Paket veröffentlichen, daß sich nicht deinstallieren
läßt, daß mir in den post-install Skripten etwas zerschießt, daß Dateien
statt in /usr/lib/foo in /usr/lib installiert, wo sie zur Laufzeit nicht
gefunden werden, oder daß beim Upgrade einer Abhängigkeit das Repository
zersägt, weil der Packager übereifrig manuelle Abhängigkeiten definiert
hat.

> Mir ist auch egal ob jemand damit Ruhm erlangen will oder nicht.

Das ist es mir in der Tat auch. Sonst würde ich nicht anderen Packagern
helfen, ohne dafür in den Changelogs namentlich erwähnt zu werden.

> Es gibt durchaus gute Gründe für 3rd party repositories.
> Einige haben aber auch bekundet, dass sie Fedora Extras unterstützen wollen.

"unterstützen" != "Aufhören, weiterhin Core oder Extras Komponenten
zu upgraden"

> > > Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche
> > > gestellt werden sollten als an die in Core.
> >
> > Ist das der Fall?
> Definitiv, sieh dir mal die spec files von Red Hat an, da wären schon mehrere 
> an fedora.us gescheitert.

Uhm, soll ich raten, warum? Red Hat hat ein vollkommen anderes Build
System. Pakete mit unvollständigen Build Requirements versagen im
Fedora.us Build System kläglich. Daher sind vollständige Buildreqs
zwingend erforderlich, bevor einer vom Build Team manuell (!) dem
Build System ein Paket übergibt. 

Red Hats Pakete für Red Hat Linux 8.0, 9 und Fedora Core entstammen zudem
nicht dem gleichen src.rpm, wie es bei fedora.us überwiegend der Fall
ist. Red Hat Linux 8.0 und 9, einmal veröffentlicht, haben nicht ständig
Updates gesehen, wie die Extras. Daher stammt z.B. die Anforderung nach
expliziter "Epoch" in versionsbehafteten Abhängigkeiten. Andernfalls gäbe
es häßliche Fälle, in denen ein Upgrade brechen könnte.

Daß spec Dateien weitestgehend bestimmt werden, ist ein Mythos. Fedora.us
hat lediglich eine Schablone als Vorgabe.

> > Was speziell mißfällt Dir?
>
> Das Hauptproblem ist wohl momentan ein fehlendes Buildsystem.

Ack. Daran wird ja eifrig gearbeitet.

> Prinzipiell halte ich es für sinnvoll, mehr oder weniger feste Maintainer für 
> ein Paket zu haben (ohne bei jedem Release eine QA für das spec file zu 
> machen)

Streich das bitte aus Deinem Kopf: "QA für das spec file". Das ist nur ein
Erfordernis, um erstmal in die Gänge zu kommen und brauchbare Extrapakete
zu bekommen, auf die andere Pakete aufsetzen können. Aber auch, daß die
Packager Erfahrung sammeln und unterstützt werden, von vornherein
brauchbare Pakete zu veröffentlichen, als daß sie still und einsam nach
einer Veröffentlichung ihr Paket Schritt für Schritt zurechtfrickeln.
Fedora.us wäre ein Rohrkrepierer geworden, wenn es das QA System nicht
geben würde. Das läßt sich ja über Bugzilla nachlesen, was da teilweise an
src.rpms mit guten Gründen bemängelt wurde. Auch Sicherheitsmängel wurden
teilweise gefunden und behoben. Der wichtigste Schritt während eines
Reviews ist der Abgleich der source tarball Prüfsumme mit dem Upstream
Projekt oder über Stichproben und Source Diffs.

> Generell halte ich QA für die spec files für nicht zwingend notwendig, IMO 
> kann man die Pakete schon für den QA Prozess per apt/yum anbieten (evtl nur 
> SRPMS).

s.o. Das hängt davon ab, wer die Pakete erstellt. Ein src.rpm mit falschen
oder schwachen Abhängigkeiten kann nach Upgrades zu einem Fremdkörper im
Repository werden und weitere Upgrades erforderlich machen. Das Fedora
Extras Konzept wird wohl auch vorsehen, daß nur kompetente Packager
Zugriff aufs Build System bekommen und sich vorher erst einige Zeit
beweisen müssen.

> Dass das für die Tester ein Risiko darstellt ist mir klar, aber es ist nicht 
> wesentlich höher als bei manuellen Download.

Doch, denn ein Paket, das im Review Repository erscheint, wird
letztendlich als "Released" betrachtet und ggf. sogar von Mirrors
übernommen. Im Gegensatz dazu befinden sich die src.rpms der Packager
irgendwo auf privatem Webspace.
 
> Mit anderen Worten: Wenn in "qa" (oder wie auch immer man das nennt) Viren, 
> Backdoors u.s.w. drin sind, wäre mir das ziemlich egal.

Wirft die Frage auf, wann sowas entdeckt würde, wenn keiner das src.rpm
untersucht? ;)

> Das Problem ist hier IMO, dass an das Buildsystem zu hohe Ansprüche gestellt 
> werden.
> 
> Mein Vorschlag:
> für Repository "qa":
>  - rpmbuild -bs in mach

?? Das baut nur ein src.rpm! Und was ist mit Abhängigkeiten? Wer baut das
i386.rpm?
 
> wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann 
> auch binär (für "stable").

Aber gerade "mach" setzt vernünftige Buildrequires voraus. Daran scheitern
bereits massig viele Pakete!

--