Probleme beim kompilieren von transcode

[Alexander Dalloz]

Am Do, den 31.03.2005 schrieb Cedric Laczny um 9:05:

> Am 31.03.2005 um 03:05 schrieb Alexander Dalloz:
> > Darf ich mal kräftig "aua!" sagen?
> > Warum meinen nur so viele User, sie könnten so mir nichts dir nichts
> > irgendwelche RPMs problem- und risikolos auf ihr System knallen, die 
> > sie
> > auf irgendwelchen RPM Suchmaschinen / Referenzierungsseiten entdeckt
> > haben?
> 
> Darf ich mal fragen, was eine derartig unnötige Aussage soll?
> Von einem doch stark vertetenen Ratgeber in dieser ML hätte ich einen 
> derartigen Kommentar nicht erwartet, sondern lieber mal einen 
> konstruktiven Beitrag zum eigentlichen Problem.

Hallo Cedric!

Sorry, dass ich erst jetzt zu einer Entgegnung auf deine Beschwerde und
Ermahung komme. Inzwischen gab es ja schon einen sachlichen
"Schlagabtausch".
Mein metaphorisches "aua!" war mitnichten sarkastisch gemeint. Es war
ein eher gequältes Seufzen, und gewiss kein Grinsen mit Schadenfreude
und Überheblichkeit. Wie Thorsten bereits erwiderte, es ging mir um ein
Problem, dass man leider allzu häufig antrifft. Es sind wirklich mehr
als genug Probleme hausgemacht, in dem Sinne, dass Fremdpakete - also
passgenau in die Distribution eingebaute Pakete/RPMs - eingespielt
werden, und dann an i.d.R. anderer Stelle "merkwürdige" Probleme
auftreten. Genau so in diesem Fall: Erst gibt es ein Hin und Her mit
Schilderungen über ein auftretendes Problem, Nachfragen und
Erklärungsversuche, um dann nach einem Dutzend Mails zu hören, dass sich
da im System Pakete befinden, die die eigentlichen, zum Release der
Distribution gehörenden Pakete ersetzt haben.
Glaube mir, ich habe nicht selten lesen müssen, dass User Mandrake oder
SuSE RPMs in ihr Red Hat Linux reingewürgt haben ("wenn es nicht will,
dann mit --force oder --nodeps - ich brauche oder will das ja").
Vielleicht ist RPM auch in mancherlei Hinsicht zu gutmütig. Ich glaube
das dpkg von Debian weigert sich etwas hartnäckiger, oder es liegt
einfach an der Tatsache, dass dpkg mehr oder weniger auf Debian
beschränkt ist, während es doch mehr als eine RPM basierte Distribution
mit deutlich unterschiedlichen RPMs (und eigenen Makros) gibt.

> Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich 
> ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin 
> ich erstmal zufrieden.

Wem vertraust du dabei, dass das RPM für FC2 sein soll? Vielleicht
zeigst du uns zur Demonstration einfach mal die URL und das genaue
Paket? rpmseek.com ist ja keine Fedora spezifische RPM Suchmaschine wie
z.b. der FedoraTracker www.fedoratracker.org.

> Die User machen das vermutlich, weil sie sich auf das Paketmanagment 
> vom RPM verlassen und nunmal bei jedem Programm und jeder Distribution 
> die Installation anders verläuft.

Weil etwas wie eine Schraube aussieht und ich auch einen Dreher habe,
der für den Kopf der Schraube passt, heißt das noch lange nicht, dass
die Schraube in das anvisierte Gewinde passt/gehört. (Auch wenn dieser
Vergleich ein wenig hinkt.)

> Woher soll man denn bei jedem Paket wissen, das zudem noch von apt-get 
> automatisch installiert wird, ob da jetzt alles 100% auf mein System 
> passt? Ich für meinen Teil bin froh, dass ich schon manche Pakete 

Zum einen sollte man sehr genau wissen, welche Quellen für Pakete man in
seinem Tool wie apt-rpm, yum oder up2date setzt. Das schließt
Zuverlässigkeit des Repository Managers ein wie auch die QA des
Repositories. Um das zu evaluieren kann man z.B. im Vorfeld
recherchieren und Feedback anderer User ermitteln.

> selbst kompilieren konnte und daraus RPMS erstellen konnte, da 
> Installation von Software unter Linux nunmal noch ein relativ 
> aufwendiger Akt im vergleich zu anderen OS wie Windows oder Mac OS X 
> ist. Ich für meinen Teil bin definitiv eher der Anwendertyp und 

Aha, wie viel und welche Software hast du denn jemals auf Windows®
Plattformen selbst kompiliert und ordnungsgemäß ins System integriert?
Der übliche Triple-Schritt "./configure, make, make install" mag zwar
verlockend einfach anmuten, erfordert jedoch schon einiges an Wissen.
Und das meine ich gewiss nicht Hochnäsig. Auch mir fehlt genügend
Wissen, vielleicht bin ich nur weitaus vorsichtiger in Bereichen, wo ich
nur sehr lückenhaft Bescheid weiß. Möglicherweise hast du auch schon mal
davon gehört, dass es Rechnerumgebungen gibt, wo den Administratoren
ausdrücklich verboten ist, Software zu installieren bzw. eigenmächtig
Updates einzuspielen. Dort findet erst ein längerer, ausgiebiger
Evalutionsprozess in expliziten Testumgebungen statt, bevor eine
Software dann freigegeben wird. Um nur ein Beispiel aus der nicht-Linux
Welt zu nennen: es gibt etliche Firmen, wo das Windows XP® SP2 nicht
flächendeckend aufgespielt wird, weil die Evaluation Probleme aufgezeigt
hat, die schwerer wiegen als jene, die ohne Service Pack Patches
existieren.

> Cedric Laczny

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.771_FC2smp 
Serendipity 16:50:29 up 1 day, 14:16, load average: 0.53, 0.51, 0.50 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-de-list/attachments/20050331/74ab7d34/attachment.sig>