Archiv verlassen und diese Seite im Standarddesign anzeigen : RPM Pakete installieren!
Hi zusammen,
also ich hab seit gestern das erste mal Linux drauf gemacht (8.0)
Hab also so gut wie keine Ahnung von Linux!
Ich hab gehört das einfachste is es rpm Pakete zu nutzen wenn man etwas installieren möchte. Nur leider bekommen ich es einfach nicht gebacken Licq oder Opera zu installieren. Ich zieh mir das Paket klicke druff und versuch es zu sinatlieren. ich muss dann mein PW eingeben und dann rattert der da weas durch. Doch dann ist da irgendwie nix installiert!
Kabn mir jemand sagen wie ich solche RPm Pakete richtig installiere???
grüße
dOOfy
also ich hab seit gestern das erste mal Linux drauf gemacht (8.0)
Linux 8.0 gibt es nicht. Meinst Du SuSE Linux 8.0 oder Mandrake Linux 8.0 oder Slackware 8.0?
Kabn mir jemand sagen wie ich solche RPm Pakete richtig installiere???
Es sollten RPM Pakete für Deine Linux Distribution sein. Besser auch für die Version Deiner Linux Distribution. Im einfachsten installierst Du rpms von einem Konsolenprogramm aus (unter X ist das z.B. xterm, konsole, rxvt, und andere) oder im Textmodus (Strg+ALT+F1), rpm -ivh dateiname.rpm oder rpm -Uvh dateiname.rpm für Upgrades.
Wie Du es nun versucht hast, wird aus Deiner dürftigen Beschreibung nicht klar. Es gibt durchaus grafische Tools zum Installieren von rpms.
Hi,
ich denke, dass Du etwas früh hier Fragen postest!!! Du solltest Dich erstmal über die Grundsätze von Linux durcharbeiten.
Linux ist nicht M$! Frei nach dem Motto:"Ich klick mal und dann passiert was - zwar nicht was ich will aber es passiert was...!"
Schau mal hier in den FAQ oder nimm das Handbuch zur Hand und versuche Linux etwas zu verstehen!
Gruss
Helge
1. Opera ist bei SuSE schon dabei.
2. Du kannst alle Pakete die du runtergeladen hast auch per YaST2 installieren.
3. verwende, wenn du es von Hand machst, immer "rpm -hUv" und nicht "rpm -hiv"
h=hash, damit zeigt er dir ein einem Balken an, wie weit er ist.
v=verbose, er sagt dir was er tut
i=install
U=upgrade
der Witz ist, dass i nicht immer die Paketdatanbank richtig aufbaut, es kann dabei passieren, dass man ploetzlich Paketeintraege verschiedener Versionen doppelt drin hat.
u dagegen baut immer auch die Datenbank neu auf und haelt sie damit konsistent. Ist ein Paket noch nicht installiert, dann wirkt U wie i, man kann also u immer zum installieren verwenden.
also:
rpm -hUv paketname.rpm
pitu
Hee.. verschreckt ihn net!!! Jeder (jedenfalls hat die meisten) hat mal so angefangen!
@dOOfy:
Ich schätze mal du hast SuSE 8.0 installiert. Du kannst mal versuchen (beim KDE - Standartoberfläche von SuSE 8.0) die Terminal Emulation (oft fälschlicherweise als Dos Oberfläche von Linux bezeichnet) zu starten. Dafür ist links unten ein Symbol, das ausschaut wie ein Monitor mit einem Curso und einer Muschel (ich hoffe die Beschreibung ist gut :D ) Darauf klickst du und es öffnet sich ein Terminal Fenster. Dort gibst du mal
licq
ein (natürlich mit Enter abschliessen)
Wenn sich licq jetzt öffnet, dann ist es installiert. Wenn nicht, dann musst du es erst wirklich installieren. Am besten so, wie es Belkira geschildert hat. (Grafische Oberfläche ist zwar ganz nett, aber man ist meistens über die gute alte Console bzw. Terminal-Emulation schneller. Wennst länger mit Linux "spielst" wirst du es auch merken. Und du wirst über die Windows User lachen, die nur auf Icons klicken)
Guter Rat für das Forum, falls du ne Frage hast, bemühe immer vorher die Suche! Denn allzu viele Fragen wurden schon viel zu oft gefragt und damit beantwortet. Ansonsten werden imma genug Leute da sein die dir helfen wollen // werden.
mfg, Henni
PS. : Verschreckt nicht imma die Linux Neulinge. Denn der 2. Schritt ist bei Linux imma der schwerste :) (installiert ist es ja schnell, aba damit länger arbeiten usw. daran muss man sich gewöhnen - aber wenn man diesen 2. Schritt gemacht hat, wird man sich fragen wie man bloss solange mit Redmon Betriebssystemen arbeiten konnte)
der Witz ist, dass i nicht immer die Paketdatanbank richtig aufbaut, es kann dabei passieren, dass man ploetzlich Paketeintraege verschiedener Versionen doppelt drin hat.
Wo hast Du denn die Begründung aufgeschnappt? Oder ist das nur bei SuSE so üblich? -i kann selbstverständlich mehrere Pakete mit gleichem Paketnamen, aber unterschiedlichen Versionen installieren. Das allerdings nur, wenn es keine Konflikte zwischen den zu installierenden Dateien gibt.
$ rpm -q kernel
kernel-2.4.18-5
kernel-2.4.18-5p
kernel-2.4.9-31p
Sowas ist vollkommen beabsichtigt.
jo, danke für die Hilfe erstmal. Ich werde gleich nach meinen Downloads mal in Linux reingehen und mal gucken wie sich die Tipps bewähren werden :)
Ich hoffe ich bekomme es jetzt gebacken. Aber glaubt es mir, das war nich meine letzte Frage :))
lol, das hoff ich doch :) (das das nicht deine letzte Frage war)
So, ich komme zwar jetzt gleich erst zum ausprobieren, aber ich hab trotzdem mal ne frage!
Belkira: ...oder im Textmodus (Strg+ALT+F1), rpm -ivh dateiname.rpm oder rpm -Uvh dateiname.rpm für Upgrades. ...
also dazu hab ich mal ne Frage. Wohin muss ich denn das rpm Paket verschieben das er es dann annimmt? ich hab das jetzt irgednwo hin gedownloaded ... Oder suht der meine Festplatte nach dem Paket durch?
grüße
Du musst in das Verzeichnis wechseln indem die heruntergeladenen Dateien liegen, und dann diese Befehle ausführen.
Gruss
Röme
Und wie wechsel ich ins Verzeichnis?
Is das erste mal das ich mit Linux arbeite :)
achja und nochwas:
wenn in der Konsole steht:
meinname@linux:~>
wo befinde ich mich dann?
Du befindest Dich in Deinem home-Verzeichnis (/home/meinname), wahrscheinlich hast Du das Programm auch in dieses Verzeichnis runtergeladen, dann kannst Du die Befehle einfach eingeben.
Gib mal den Befehl ls -l ein, dann kannst Du sehen ob sich die Dateien in diesem Verzeichnis befinden.
Verzeichniswechsel machst Du mit dem Befehl cd (z.b. cd /home/mainname/downloads)
Gruss Röme
Belkira, glaubs mir einfach, wenns unguenstig laeuft, kannst du bei -i ein paket mit verschiedenen Versionen DOPPEL in der Paketdatenbank haben, und das hat auch nix mit SuSE zu tun, sondern mit RPM.
Das kommt einfach daher, dass der Schalter "i" die Datenbank nicht neu aufbaut, dabei kann es zu Fehlern kommen. Bei -u wird die Datenbank auf jeden Fall wieder aufgebaut.
Ich hab doch nicht gesagt, dass das immer so ist, nur, das es unter unguenstigen Umstaenden passieren kann, dass man das aber verhindern kann, indem man einfach den Schalter U verwendet.
pitu
cd /home/mainname/downloads
also ich bin soweit das ich weiß wo ich bin, nur leider kann ich den oben genannten Befehl nicht anwenden!
Also wenn ich Is -I eingebe steht bei mir unter anderem der ordner Documents wo ich alle sachen drin habe. wenn ich jetzt aber schreibe:
cd /Documents/
...dann passiert nix und er sagt Verzeichnis nicht gefunden!!
Wenn Du vom aktuellen Verzeichnis in ein Verzeichnis unterhalb dieses Verzeichnisses wechseln willt musst Du den ersten Slash weglassen, also mittels
cd Documents
ins Verzeichnis Document wechseln, der erste Slash benötigst Du wenn Du einen absoluten Pfad angibst.
Gruss
Röme
OK,
ich bin im Verzeichnis, ahbe jetzt den richtigen Befehl eingegeben, und was passiert? er sagt ich hätte nich die Berechtigung
Du musst den Befehl als root ausführen, gib den Befehl
su
ein und das root Passwort.
Danach wieder den Befehl zur Installation des Programmes.
Gruss
Röme
So das hab ich nun auch alles gemacht und nun sagt er das:
Fehler: fehlgeschlagene Paket-Abhängigkeiten:
libjscript.so.2 wird von kxicq-03132000-1 gebraucht
libkdecore.so.2 wird von kxicq-03132000-1 gebraucht
libkdeui.so.2 wird von kxicq-03132000-1 gebraucht
libkfile.so.2 wird von kxicq-03132000-1 gebraucht
libkfm.so.2 wird von kxicq-03132000-1 gebraucht
libkhtmlw.so.2 wird von kxicq-03132000-1 gebraucht
libkimgio.so.2 wird von kxicq-03132000-1 gebraucht
libmediatool.so.2 wird von kxicq-03132000-1 gebraucht
libqt.so.1 wird von kxicq-03132000-1 gebraucht
aja
:ugly:
Belkira, glaubs mir einfach, wenns unguenstig laeuft, kannst du bei -i ein paket mit verschiedenen Versionen DOPPEL in der Paketdatenbank haben, und das hat auch nix mit SuSE zu tun, sondern mit RPM.
Du kannst das weder nachvollziehbar begründen, noch hast Du offenbar meine Begründung gelesen. Vielleicht gehörst Du auch zu denjenigen, die oft mit --force herumspielen. RPM prüft neu zu installierende Pakete auf Konflikte mit der RPM DB und installiert nichts aus "Versehen" doppelt, wenn Zieldateien bereits in der DB existieren. Mit RPM und später Red Hat Linux 4.x aufwärts habe ich sowas in vielen Jahren nocht nicht gehabt.
Das kommt einfach daher, dass der Schalter "i" die Datenbank nicht neu aufbaut, dabei kann es zu Fehlern kommen.
Wo läßt sich sowas nachlesen? Was meinst Du mit Datenbank "neu aufbauen"? Hast Du schonmal mit -ivvvh installiert?
Ich hab doch nicht gesagt, dass das immer so ist, nur, das es unter unguenstigen Umstaenden passieren kann, dass man das aber verhindern kann, indem man einfach den Schalter U verwendet.
Und ich hab geschrieben, wenn Du ein kaputtes System hast, wo sowas vorkommt, dann liegt es nicht an RPM, sondern an Deinem System oder Deiner Linux Distribution.
Also ich hab mir licq nochmal runter geladen und zwar heißt das Palket:
licq-1.0.3-1.i386.rpm
ich habe SuSe Linux 8.0
is das die richtige licq version? Gibt so viele da ;-)
Naja auf jedenFall, wenn ich das Paket installiere dann kommt das hier:
linux:/home/meinname/Documents/Downloads # rpm -ivh licq-1.0.3-1.i386.rpm
Fehler: fehlgeschlagene Paket-Abhängigkeiten:
libcrypto.so.0 wird von licq-1.0.3-1 gebraucht
libssl.so.0 wird von licq-1.0.3-1 gebraucht
linux:/home/meinname/Documents/Downloads #
Hi,
Mit der Version wirst Du nicht viel Freude haben, da sie ziemlich veraltet ist. Das aktuellste Paket für SuSE als RPM bekommst Du hier:
http://www.kawo1.rwth-aachen.de/~lurchi/licq/licq-20020506-1_qt3.i586.rpm
Die zwei Bibliotheken die in der Fehlermeldung erscheinen, gehören zu dem Paket OpenSSL. Das Paket ist auf den SuSE-CD?s mit drauf, kannst also mittels Yast einfach nachinstallieren.
Gruß micha
Original geschrieben von Belkira
Du kannst das weder nachvollziehbar begründen, noch hast Du offenbar meine Begründung gelesen. Vielleicht gehörst Du auch zu denjenigen, die oft mit --force herumspielen. RPM prüft neu zu installierende Pakete auf Konflikte mit der RPM
Nachvolllziehbar begruenden: eigene Erfahrung, ich hab schon meinen eigenen Installer geschreiben, Netzwerkweite Installation und automatische Updates Basierend auf Abteilungen. Und zuviel mit force habe ich auch nicht rumgespielt.
DB und installiert nichts aus "Versehen" doppelt, wenn Zieldateien bereits in der DB existieren. Mit RPM und später Red Hat Linux 4.x aufwärts habe ich sowas in vielen Jahren nocht nicht gehabt.
Ich schon, aber eben mit -U noch nicht.
Wo läßt sich sowas nachlesen? Was meinst Du mit Datenbank "neu aufbauen"? Hast Du schonmal mit -ivvvh installiert?
Hast du schon mal Pakete nach -I doppelt gehabt? Anscheinend nicht, ich schon. -I machts eben nicht so sauber wie -U
Und ich hab geschrieben, wenn Du ein kaputtes System hast, wo sowas vorkommt, dann liegt es nicht an RPM, sondern an Deinem System oder Deiner Linux Distribution.
Ausserst unwahrscheinlich, dass es am System oder an der Distri liegt, wenn RPM es falsch in die Datenbank eintraegt. Ich hab selber schon genug Pakete gemacht.
Lass gut sein, ich hab meine Erfahrungen und du glaubst sie mir nicht.
pitu
Hast du schon mal Pakete nach -i doppelt gehabt?
Natürlich. Aber dann existierten zwischen den Inhalten beider Pakete keine Konflikte. Und sowas sieht RPM ja ausdrücklich vor (siehe mein Beispiel mit kernel-Paketen, siehe Option --allmatches). Etwas formaler: Wenn die Menge der zu installierenden Dateien zweier rpms disjunkt ist, genau dann lassen sich zwei rpms unter gleichem Paketnamen installieren.
Nun kommst Du und behauptest, RPM würde bei Verwendung von -i versehentlich Pakete mit gleichem Paketnamen (und wahrscheinlich gleicher oder unterschiedlicher Version) mehrfach installieren, folglich die rpmdb ignorieren und Dateien auf der Festplatte überschreiben.
Mein Kommentar dazu ist, daß ich dies nur bei Softwarefehlern für möglich halte, wenn die rpmdb zerhackt oder irgendwie beschädigt war, die Integrität und Funktion Deiner rpmdb also nicht sichergestellt war oder Dein RPM Bugs hatte. Wann immer ich ein oder mehrere Pakete mit -i installiert hatte, war die rpmdb gleich nachher auf dem neuesten Stand.
Nachvollziehbar ist Deine Erfahrung für andere User keineswegs, es sei denn, sie machen eine ähnliche Erfahrung. Meine Erfahrung ist, User arbeiten zu oft mit --force oder installieren konfliktfreie rpms, deren Dateiname vom Paketnamen abweicht und ein Paket nach /usr, das andere nach /usr/local oder /opt installiert wird.
Nachvollziehbar wäre, wenn Du Fakten zur spezifischen Arbeitsweise von RPM nennen könntest, die beweisen, daß rpm -i solche Patzer, wie Du sie beschreibst, unterlaufen können und das schon über Jahre.
Es ist ja sehr schoen dass RPM das vorsieht, aber jetzt versuch doch mal das Paket zu deinstallieren, --almatches ist ja ganz schoen, aber wenn du nur das eine wech haben willst ....
Genau dazu ist eine Saubere Datenbank ja da, und wenn ich meine Pakete nicht entsrechend Pflege und deswegen soetwas vorsehen muss, dann ist das der gleiche Mist wie unter Windows wo beim deinstallieren auch die haelfte uebrigbleibt.
Pakete doppelt zu haben ist schlicht und einfach mist. Damit werden System mit schlecht gepflegten Paketen auf die Dauer nicht wartbar und wenn ich von wartbar rede meine ich nicht 10 oder 20 Rechner sondern 100 oder mehr.
Und wenn soetwas sogar vorgesehen ist dann nur weils am konzept gemangelt hat.
pitu
aber jetzt versuch doch mal das Paket zu deinstallieren, --almatches ist ja ganz schoen, aber wenn du nur das eine wech haben willst ....
No problem: rpm -e %{name}-%{version}-%{release} / die Variablen natürlich passend ausfüllen.
Beispiel: rpm -e kernel-2.4.9-31p
Pakete doppelt zu haben ist schlicht und einfach mist.
Hast Du mein exzellentes Beispiel von oben nicht gesehen? Hier nochmal:
$ rpm -q kernel
kernel-2.4.18-5
kernel-2.4.18-5p
kernel-2.4.9-31p
Das ging damals nicht so ohne Probleme.
Wenn es inzwischen geht, ist es zumindest tolerierbar, in Spezialfaellen (z.B. Kernel). Fuer eine allgemeine Versionskontrolle wenn man verschiedene Arbeitsumgebungen braucht ist es zu schwach und zu fehleranfaellig (libraries, compiler, configfiles etc).
Dazu ist eine Paketverwaltung definitiv nicht da.
pitu
Wenn es inzwischen geht, ist es zumindest tolerierbar, in Spezialfaellen (z.B. Kernel).
Original util-linux in /usr, zweites util-linux gepatched für PPDD in /usr/local. Wunderbar! libfoo-1.x und libfoo-devel-1.x in /usr/lib und /usr/include/foo1, libfoo-2.x und libfoo-devel-2.x in /usr/lib und /usr/include/foo2. Ebenso wunderbar! Wie würdest Du paketbasierte Installation von mehreren Kernels oder Libs sonst lösen?
Fuer eine allgemeine Versionskontrolle wenn man verschiedene Arbeitsumgebungen braucht ist es zu schwach und zu fehleranfaellig (libraries, compiler, configfiles etc).
Versteh ich nicht. Was ist zu schwach und zu fehleranfällig? Wohl eher ungeschickte Paketnamensgebung bei verschiedenen Arbeitsumgebungen. Arbeitsumgebungen sind günstigerweise in eigenen chroot-Umgebungen. Unter Red Hat Linux 7.3 laufen z.B. GCC 2.96 und GCC 3.1 ganz gewöhnlich im gleichen System, weil es keine Konflikte zwischen den Paketen gibt.
Verschiedene Programme in verschiedenen Versionenbrauchen eventuell verschiedene Versionen von Libraries, brauchen eventuell verschieden gesetzte Umgebungsvariablen und koennen sich moeglicherweise gegenseitig stoeren.
Es ist die Aufgabe eines Versionsystems, diese Problematik zu loesen. Die Aufgabe eines Paketmanagments ist es, fuer ein laufendes System zu sorgen, Konflikte und Abhaengigkeiten aufzuloesen und dafuer zu sorgen, bzw. die Mittel dafuer zur Verfuegung stellen, dass das System stabil bleibt.
Man kann mit einem Paketsystem Pakete in ein Versionsystem einspielen, die Verwaltung soll es dann aber bitte an jemanden Abgeben, der darauf spezialisiert ist weil er es besser kann, bzw besser darauf ausgelegt ist.
Fuer kleine Sachen wie z.B. deinen Kernel geht das ja noch in Ordnung, wenn das im Paketmanagment drin ist.
Nur um die zu sagen was ich meine:
Pfad: /versionscontrolle/<programm>/<version>/
Befehl: switch <programm> <version>
mit anderen Worten, das Versionsystem hat ein eigene Verzeichniss, darunter liegen verschiedene Programmverzeichnisse, darunter verschiedene Versionen des Programms mit einer kleinen Datenbank die alle Abhaengigkeiten enthaellt.
Mit dem Befehl bindest du nun die neue Version ins System ein.
Gebraucht wird soetwas z.B. in der Entwicklung wenn viele Leute, eventuell noch an verschiedenen Standorten an verschiedenen Projekten arbeiten.
Da kannst du nicht einfach mal eben einen neuen oder alten Compiler samt aller Header und Libraries im laufenden System austauschen. Das Ding ist schliesslich ein Produktivsystem.
Du hast vieleicht ein aelteres Projekt in dem du einen aelteren Compiler brauchst davon haengen noch ein paar libs ab,eventuell werden scripte benutzt und dafuer brauchst du von zusatztools wieder andere Versionen....
Ein Paketsystem schafft das nicht, vor allem dann nicht, wenn auf einer Kiste gleichzeitig mehrere leute eingeloggt sind die verschiedene Arbeitsumgebungen haben, und jeder an einem anderen rojekt arbeitet ubd er gerade ein paar scripten von einem anderen Standort bekommen hat, bei dem einige Sachen im System anderes aufgebaut sind.
Ein Paketsystem ist fuer mich nur dazu da, mich als admin dabei zu unterstuetzen, das Produktivsystem stabil zu halten und zu nix anderem.
Das meinte ich damit. und du kannst nicht sagen dass es Aufgabe eines Distributrs ist, seine pakete so aufzubauen, dass dass da oben laeuft, ganz zu schweigen davon, dass das mit keinem aketmanagmenttool moeglich ist, weder mit swinstall von HPUX, noch mit pkgadd von Solaris und auch nicht mit RPM und DEB von linux.
pitu
Ein paar Zitate, weil Du meiner Ansicht nach zu weit abschweifst. Ich weiß nicht, warum Du das tust und wo Du ein Problem siehst. Aus diesem Deinen Posting wird es auch nicht klar.
Verschiedene Programme in verschiedenen Versionenbrauchen eventuell verschiedene Versionen von Libraries, brauchen eventuell verschieden gesetzte Umgebungsvariablen und koennen sich moeglicherweise gegenseitig stoeren.
Es ist die Aufgabe eines Versionsystems, diese Problematik zu loesen.
Aufgabe eines Versionssystems, aber nicht Aufgabe einer Paketverwaltung. Paketverwaltung und Umgebungsvariablen spielen in einer gänzlich anderen Liga. Wie ich zwischen Qt 2 und Qt 3 umschalten kann oder sie sogar parallel betreiben kann, hat nichts mit der Paketverwaltung zu tun.
Die Aufgabe eines Paketmanagments ist es, fuer ein laufendes System zu sorgen,
Ich weiß, was Du meinst, aber nein, das Paketmanagement kann dies nicht garantieren. Es sei denn, die in den Paketen verankerten Abhängigkeiten sind eindeutig und vollständig und die Programme zudem ordnungsgemäß und konfliktfrei compiliert.
Konflikte und Abhaengigkeiten aufzuloesen und
Konflikte prüfen und vermeiden bzw. verbieten, über Abhängigkeiten bescheidwissen. Die Hauptverantwortung geht aber auf den Packager über, der die Pakete und Abhängigkeiten erstellt.
dafuer zu sorgen, bzw. die Mittel dafuer zur Verfuegung stellen, dass das System stabil bleibt.
Negativ. Wenn ich eine Library mit Bug installiere, wird das System instabil. Sowas kann die Paketverwaltung nicht verhindern, wenn ich im Fall von RPM mit -U arbeite, anstatt mit -i, und wenn ich Abhängigkeiten ignoriere oder eine Lücke in Abhängigkeiten nutze (z..B. libfoo 1.4 installiere, wenn libfoo >= 1.2 benötigt ist, die Packager noch nicht wußten, welche Änderungen libfoo > 1.3 bringen wird). Wenn ich als Entwicklern eine neue Lib in /home/foobar installiere und den LD Pfad verbiege, komme ich möglicherweise ebenso in Schwierigkeiten.
Pfad: /versionscontrolle/<programm>/<version>/
Befehl: switch <programm> <version>
Ich denke hier u.a. an das von Red Hat adaptierte "Debian Alternatives", postfix und sendmail parallel installiert. Sowas hat mit der Paketverwaltung nichts zu tun. Die sorgt nur dafür, daß sich Pakete installieren lassen, wenn es keine Konflikte unter ihnen gibt. Den Rest muß zusätzliche Software erledigen, z.B. chroot-Umgebungen. Versionskontrolle für Libs findet auf Linkerebene statt. Was stört das System eine Lib irgendwo in /usr/lib/blah? Garnicht, solange sie nicht in den Suchpfad eingebunden ist.
Bevor wir hier weiter diskutieren, sollten wir uns vielleicht auf ein paar gezielte Fragestellungen einigen. Ich kann bloß weiterhin Deine Kritik an RPM bzw. rpm -i nicht nachvollziehen, außer, daß Du scheinbar extrem schlechte Erfahrungen mit RPM gemacht haben mußt.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.