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

[Ronny Buchmann]

On Thursday 29 January 2004 01:25, Michael Schwendt wrote:
> On Wed, 28 Jan 2004 23:47:57 +0100, Ronny Buchmann wrote:
> > On Wednesday 28 January 2004 15:15, Michael Schwendt wrote:
> > > On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
> > > > Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum
> > > > die Vermutung der "ideologischen" (vielleicht etwas irre leitender
> > > > Ausdruck) Nähe.
> > >
> > > *Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich
> > > abhängig von mail > /dev/null Symptomen und der Lust und Laune einer
> > > Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig
> > > war, um einfach nur die neueste Version "herauszuhauen".
> >
> > "etwas mehr Zeit"? Gegen "etwas" hat kaum jemand etwas, von "etwas" kann
> > aber keine Rede sein.
>
> "Etwas" mehr ist aber notwendig, um Probleme entweder von vornherein zu
> reduzieren oder sie nachher zu beheben. Ein altes src.rpm von z.B. Red Hat
> Powertools zu nehmen, einen neuen source tarball einzufügen und vielleicht
> noch ein paar configure Parameter oder Abhängigkeiten manuell anzupassen,
> ist keine Leistung. Eine Leistung entsteht aus sowas erst, wenn dabei
Mir ist es egal ob in einem spec file viel oder wenig Arbeit steckt. Mir ist 
auch egal ob jemand damit Ruhm erlangen will oder nicht.


> > fedora.us würde auch von den (bisherigen) Packagern benutzt werden, wenn
> > der QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)
>
> Wann wäre er angemessen?
>
> (Haben nicht einige der "bisherigen Packager" verlauten lassen, daß
> sie nichtmal ein offizielles Fedora Extras unterstützen wollen, sondern
> ein "3rd party repository" bleiben wollen?)
Es gibt durchaus gute Gründe für 3rd party repositories.
Einige haben aber auch bekundet, dass sie Fedora Extras unterstützen wollen.

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

> Was speziell mißfällt Dir?
Das Hauptproblem ist wohl momentan ein fehlendes Buildsystem.
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)

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

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

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.


> > Eine QA-Warteschlange für unstable/testing zu haben ist einfach nur
> > krank.
>
> Wie sollte es bei einem manuellen Build System anders aussehen?  Dann
> hätte das Build Team nichts anderes zu tun, als Pakete abzuweisen, die
> vor, während oder nach der Compilierung kläglich scheitern, nichtmal
> funktionieren, mit falschen Dateizugriffsrechten versehen sind oder so mit
> manuell gesetzten Abhängigkeiten bestückt sind, daß es beim nächsten
> Update Problem gibt.
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

wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann 
auch binär (für "stable").

> Ein öffentliches Community Packaging Projekt verlagert zudem leider einen
> Teil der Paketentwicklung in das QA System.
>
> Anders sähe es aus, wenn der Packager ein automatisiertes Build System
> verwenden könnte, das sicher gegen Einbruchversuche von außen und innen
> ist. Aber selbst dann könnte er Pakete bauen, die mit gefährlichen oder
> unsinnigen Abhängigkeiten ausgestattet sind und zu Problemen führen.
s.o.

> Aber warum sollte das QA System für testing/unstable wegfallen? Damit
> würde ja auch der MD5 Abgleich des Upstream Source und ein Blick in das
> spec Skript oder Patches wegfallen. Unverantwortlich.
s.o.

cu
ronny