Bernhard Walle wrote:
Hallo,
On Sun, Oct 08, 2000 at 16:19 +0200, Wolfgang Weisselberg wrote:
Bernhard Walle schrieb in 12K (346 Zeilen):
On Fri, Oct 06, 2000 at 23:36 +0200, Wolfgang Weisselberg wrote:
Bernhard Walle schrieb in 7,8K (227 Zeilen):
On Thu, Oct 05, 2000 at 1:15 +0200, Wolfgang Weisselberg wrote:
Du wirfst sicher auf jedes Programm, das Du installierst einen Blick darauf.
Mit Sicherheit auf jedes, welches nicht von einer Quelle stammt, von der ich nicht auch Binaries nehmen wuerde.
Ich habe für so überflüssige Tätigkeiten keine Zeit. Dann würde ich Dir empfehlen, von der Installation von Programmen vom Soucecode Abstand zu nehmen - Niemand zwingt Dich dazu :)
Wenn Du allerdings vom Sourcecode installieren willst, solltest Du Dir die Zeit nehmen -- alles andere wäre grob fahrlässig.
Code und Techniken lernen ist ueberfluessig? Hmmm.
Das nicht, aber alles durchzuschauen ist für meinen Anwendungsbereich überflüssig.
"Alles zu durchschauen" ist auch nicht verlangt, doch einige Grundlagen sollte man schon mitbringen. Diese Dinge mögen Dich im Augenblick nur am Rande betreffen, neu für dich neu sein und einen gewissen Aufwand mitbringen, doch dieser Aufwand rentiert sich spätestens dann wenn Du einmal reingefallen bist. Dies passiert selbst erfahrenen Profis und selbst den Distributoren immer wieder.
Soll ich erst C und dann C++ lernen, bevor ich ein Programm installiere?
Du solltest mindestens eines von beiden lernen. Einfach so.
Habe ich ja auch mal vor. Aber so lange möchte ich mit dem Installieren von Programmen nicht warten.
Du willst Dein Auto umbauen/tunen, ohne zu wissen was ein Schraubenschlüssel ist? Entweder brauchst Du Mechanikergrundkenntnisse (Hier: Grundkenntnisse der Programmierung), eine Werkstatt (Hier: SysAdmin oder externer Dienstleister) oder aber Du musst warten, bis der Hersteller es serienmässig anbietet (Hier: Dein Distri).
Du hast wirklich seltsame Vorstellungen.
Jeder Mensch sollte ein Grundverstaendniss von Computern haben.
Das ist aber nun etwas übertrieben. Richtig wäre:
Jeder Mensch, der mit Computern arbeitet, sollte ein Grundverständnis von Computern haben.
Mit Deiner Behauptung würdest Du von meiner Oma verlagen, dass sie sich mit Computern auskennt.
Haarspalterei :) Wenn sie allerdings mit Computern arbeiten will, würde ich es Ihr nahelegen.
Seit wann muss der Inhalt eines SRPMs was mit dem RPM zu tuen haben? Ein SRPM ist nichts anderes als ein glorifizierter Teerball, der nicht tar verwendet und ein .spec-File an
Ja klar, aber wer will, kann übersetzen, wer nicht will, lädt sich das fertige RPM und hat Binarys. Um das geht es.
Und ich dache OSS, GPL und Co haetten noch andere Ziele.
Kann man mit SRPM nicht den Quellcode anschauen?
Mit SRPM? Nein. Die SRPMS beinhalten normalerweise einen TAR-Ball und eine Spec-Datei, die beschreibt, wie sich ein Distributor vorstellt, wie ein Paket zu konfigurieren, zu übersetzen und zu installieren sei.
Es hindert Dich keiner, die Scripte, die bei den RPMs drin sind, durchzulesen, bevor sie ausgeführt sind.
Falsch. Ein Trigger eines anderen RPMs kann bei Installation ein im RPM enthaltenes Programm/Script ausfuehren. Ich muesste erst das RPM auspacken (z.B. alien), oder mit --notriggers 2 mal installieren.
Mit dem mc kann man doch die Skripte anschauen, ohne sie auszuführen.
Wozu mc ? :) less, more, vi, emacs, joe ...
Wenn Du einen Compiler installierst, wird er Headers und Includes bemängeln. Woher weiß RPM denn, welche Includes und Headers Du installieren sollst? QT? GTK? X-Devel?
[ ] Du kennst RPM.
Hier hast Du ein X vergessen.
Bin ich mir nicht sicher. Wieviele RPMs hast du schon gebaut? Hast du MaximumRPM gelesen?
Gebaut keins. Installiert viele.
:) Das Programm "rpm" ist ein Werkzeug, das aus Input (tar, patches, *.spec) ein Produkt (*.rpm, *.srpm) generiert. Ähnlich wie ein Compiler noch lange kein funktionsfähiges Programm generiert, ist rpm nur so intelligent wie der Autor einer *.spec und so intelligent wie die Autoren des Programmes "rpm". Es kann somit nur das berücksichtigen, was die Autoren einer *.spec und die Autoren von "rpm" berücksichtigt haben. Leider ist das Schreiben von *.specs, von Trivial-Fällen abgesehen (diese decken allerdings 90% der Fälle ab), keinesfalls einfach. Schau Dir doch mal die *.specs komplexer Pakete an. Du wirst vermutlich überrascht sein, mit welchen Problemen die Autoren der *.specs und das Programms "rpm" zu kämpfen haben. Das dem so ist, ist aus meiner Sicht zu wesentlichen Teilen ein Defizit des Systems "rpm" und ist auch ein Grund dafür, warum ich mich am Anfang dieses Threads gegen Deine Begeisterung für "rpm" ausgesprochen habe. IMNSHO kann RPM nicht der Weisheit letzter Schluss sein, weshalb ich Alternativen sehen will.. :)
Wenn ein 'Normaluser' fragt, "kann ich das Programm installieren", dann sage ich ihm, "leg's nach /usr/local".[1] "Gibt's kein RPM?" - "Nein"[2] a) "Oh. Schade. Also nicht."
Eben, und mit RPM kann auch a) ein Programm installieren.
Nein, da RPMs oft Distri-abhaengig sind (auch in den provides/requires Namen).
Und das sollte sich ja ändern. Das war der Ausgangspunkt. Sprich mit den Distributoren. rpms liessen sich in sehr vielen Fällen distributionsunabhängig gestalten.
Doch selbst wenn das nicht möglich ist, lassen sich srpms eigentlich immer so gestalten, dass ein Neuübersetzen des SRPMS auf der Zieldistribution ein Binär-rpm an die speziellen Anfordungen automatisch anpasst. Dass dies in der Praxis nicht immer der Fall ist, liegt meist daran, dass die Autoren der *.specs dies schlichtweg nicht berücksichtigt haben. Beispielsweise passen sich sauber geschriebene RH-6.x-SRPMs an SuSE an, SuSE's SRPMS aber nur selten an RH, da die meisten SuSE *.specs SUSE-proprietäre Erweiterungen von RPM nutzen, die unter RH nicht zu Verfügung stehen. Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com