Hi!!
Wie kann man auf suse 10.2 progs selber ohne YAST installiern ich meine in der Konsole??
mfg chris
chriz63 (187) 2x Beste Antwort 2x "Danke"
|
chriz63 (187) 2x Beste Antwort 2x "Danke"
|
Hi!!
Wie kann man auf suse 10.2 progs selber ohne YAST installiern ich meine in der Konsole??
mfg chris
Das kommt darauf an, in welcher Form du das programm vorliegen hast.
rpm, source (meist gepackt in tar-Archive) usw.
bei rpm gibt es folgenden Befehl:
rpm -ihv paketname.rpm
Bei Source ist eine Installationsanweisung meist im Archiv zu finden. Desweiteren geben dir meistens die Anbieter Installationsanweisungen auf deren Webseite.
'rpm' hat allerdings den Nachteil, das es keine Abhängigkeiten auflösen kann, insofern es in den meisten Fällen eine ziemlich unkomfortable Lösung darstellt. Zwei sehr schöne Konsolenproggies zum Installieren unter SuSE sind das hauseigene tool zypper sowie smart - ich nutze letzteres sehr gerne, zumal es in der Konsolenvariante ein gutes Stück fixer ist als YaST (welches zwar schneller geworden ist, aber immer noch kein Vergleich zu smart...).
smart empfehle ich auch deshalb, weil es ein wenig flexibler ist als zypper, und neben YaST- und rpm-md-Quellen auch z.B. Yum- und apt-Quellen verwalten kann, zudem empfinde ich die Syntax als etwas einfacher. Probiere es mal aus.
Edit: Links vergessen...
smart » klick
zypper » klick
zuerst musst mal das Archiv entpacken und meist befindet sich im Archiv eine Readme oder install-Anweisung. Dort seht dann alles was wissen musst.
Hier ein Beispiel einer Installationsanweisung:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes a while. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Type `make install' to install the programs and any data files and
documentation.
4. You can remove the program binaries and object files from the
source code directory by typing `make clean'.
Compilers and Options
=====================
...........
Sorry Snatcher, aber der leider viel zu oft zitierte Dreisatz ist wirklich die allerschlechteste Methode, ein Paket zu installieren. Mit 'make install' wird eine Anwendung an der Paketverwaltung vorbei installiert, und entzieht sich somit auch der Einbindung in das gesamte Systemmanagement. Es kann nicht upgedatet werde, nicht deinstalliert (sofern kein uninstall-skript verfügbar ist), unter Umständen werden etliche Ordner und Dateien Quer durchs System angelegt, die kein Mensch mehr wiederfindet. Macht man derlei öfter, zerschießt man sich nach und nach sein System.
Wenn man schon sourcen selber übersetzt (was zum Beispiel unter openSUSE selten notwendig ist, da die Repositories einen äußerst umfangreichen Fundus an Paketen beinhalten), sollte man auch lernen, ein über die Paketverwaltung installierbares Paket (in SuSEs Fall .rpm) zu bauen.
Für's schnelle .rpm-Bauen eignet sich » checkinstall sehr gut.
Aber wie gesagt, sinnvoll ist das selten, solange man die Pakete über Repositories beziehen kann. Wenn man ohnehin keine speziellen ./configure-Optionen in den Kompiliervorgang einbaut, macht es keinen Unterschied, ob man das selber übersetzt oder über das Paketmanagement geht.
Hallo
Manchmal geht das nicht anders ! z.B. Bei svn snapshots von madwifi
oder auch der iwl Treiber von Intel checkinstall ist da echt zu empfehlen so bekommt man die Pakete schnell aus den System ! Aber das beste sind immer noch *src.rpm`s z.B. wenn man einen anderen Kernel fährt so sind schnell die kmp module gebaut für den neuen Kernel ! make install ist echt nicht zu empfehlen ! Aber die Repos. von openSuse sind so gut gefüllt das man kaum auf ein Paket verzichten muss deswegen gilt eins nutze nur den PaketManager so bleiben ungeliebte folgen aus weil alle abhänigkeiten aufgelöst werden !
Mfg
Schmolle
Was schmolle hier sagt, ist von vorne bis hinten korrekt und sollte unbedingt beherzigt werden. Die Berücksichtigung des Paketmanagers auch beim Übersetzen von sourcecodes ist nicht nur übersichtlicher, sondern führt häufiger zum erwünschten Ergebnis.
Zum Thema src.rpms (eine weitere sehr interessante Methode des .rpm-Bauens) poste ich hier mal zwei sehr schöne Beispiele meines hochgeschätzten Forumskollegen RAIN_MAKER aus der Praxis:
- Fritzcard-Treiber aus src.rpm bauen
- RPM-Umbau aus einem src.rpm mit "rpmbuild"
Mittels 'rpmbuild' kann man im Gegensatz zu 'checkinstall' konforme Pakete bauen, die sich auch auf anderen Rechnern einsetzen lassen.
« Suse: 10.3 3D-Beschleunigung | Suse: phpMyAdmin Autorisierungsproblem » | ||