Mandrake 9.1 und RPM

hallo ich versuche Softwarepakete mit RPM zuinstallieren,es klappt absolut nicht, kann mir jemand ein Tip geben , was ich genau beachten muß
mfg

 

Wie ich schon schrieb, in dem Fall kannst du den ersten Absatz vergessen. (Aber der Smiley gefällt mir! (: ) Die anderen beiden behalten inklusive aller Fragen aber ihre Gültigkeit.

 

@ Cirad

Ich habe nicht die samba sourcen, sondern die /etc/apt/source.list gemeint

MfG

 

Also erstmal ist es schlecht, am Paketsystem vorbei etwas in sein "Bereich" zu installieren, zumindest sofern das Paketsystem irgendwas mit RPM, DPKG oder Portage zu tun hat. <:
Das ist genauso, wie im VW-Werk auf das Fließband eine Gummiente zu legen. Das verwirrt einfach. <:
Solche Sachen würde ich daher in ein extra Verzeichnis installieren, oder die Source-DEBs nutzen (falls du das nicht hast).
Falls du mit Sourcen die apt-Sourcelist meinst, kannst du den Absatz hier vergessen.

Zweitens ist apt-get nur ein Frontend für dpkg. Die Backends sind im Zweifel doch immer den Frontends vorzuziehen.

Und was hat beim Deinstallieren nicht funktioniert? Bei einzelnen Files, die nicht installiert werden können, fallen mir mehrere Möglichkeiten ein, die allerdings aus deiner Beschreibung resultieren. Mehr Infos wären schön, eventuell stellt sich das ein oder andere dann sogar als Feature heraus.
Und was heißt "Sourcen initialisieren"? (Der einzige interessante und relevante Schritt ist make install.)

 

@ Killermaster:

Wenn dus genau wissen willst, hab ich bei der installation mit den sourcen gepfuscht. Also habe ich die source-initialisierung nochmal abgebrochen, um nur die woody-cd zu verwenden. Später hab ich das ganze (nach der installation) nochmal editiert. Und siehe da, apt-get kann die unvollständige samba-version nicht deinstallieren, die neue kann dann nicht konfiguriert werden etc...

ka, ich habe debian nur zum testen installiert, ich bleibe weiterhin bei den rpm-basierten systemen. (wobei ich nicht rh, susi oder fedora meine)

MfG

 

der hatte probleme , dass er smbd nicht starten konnte.
LOL
und ich bin mir ziemlich sicher dass er nach erstem
apt-get install samba
bei der konfiguration einiges falsch gemacht hat

:-)

mfg

 

@blakcomb:
Nun mach es nicht so spannend.
Was hat denn nicht funktioniert?
Und was nutzt du? stable, testing oder unstable?

Das du ein bestimmtes Paket als Beispiel bringt, bringt uns vermutlich genau zu der Sache, die ich oben erwähnte: "Vorsicht, nicht Frontend und Paket verwechseln." Aber schauen wir mal. (:

Lustigerweise ist übrigens gerade der Entwickler und Initiator der Paketverwaltung absolut kein Freund von apt-get. Leider kenne ich die Gründe nicht mehr ... liegt vielleicht daran, daß er sie im Interview nie erwähnt hatte. Weiß nicht mehr. (:
Wobei ich apt-get einigermaßen in Ordnung fand und recht zufrieden damit war.

 

LLOOOOOLL
das lag an dir blackcomb :P

mfg

 

ich war fest davon überzeugt, dass apt-get idiotensicher ist... was bei einem "apt-get remove samba" und einem anschlieSenden "apt-get install samba" nicht funktionieren kann, hab ich mich auch gefragt...

mfg

 

z.B. totem
ich konnte irgendwie totem nicht installieren.
mfg

 

BTT? Was meinst du, kann man zu "geht nicht" so genau schreiben? Eventuell ist auch meine Glaskugel einfach kaputt. <:

PS: Was funktioniert denn an apt-get nicht? (Vorsicht, daß du nicht Paket und Frontend verwechselst. (: )

 

Mdk hat ein wunderbares tool zum installieren von rpm-s. urpmi ist eine alternative für apt-get. So problemlos funktionierts bei debian nun auch wieder nich...

MfG

 

Danke für deine Mühe, aber das war mir bekannt.
Du hast es Side by Side nur hervorgehoben, als sei es etwas besonderes, daher meine Frage, was es denn noch tolles kann, außer Probleme zu lösen, die andere seit Jahrzehnten gelöst haben.

Die ganze Shared-Libraries-Geschichte unter Windows war bisher ein einziges Disaster, die Lösungsansätze wie einfach den Austausch von Libs zu verbieten oder woanders hin zu installieren pervertierten noch dazu deren Funktionalität und waren von stupider Trivialität.

Dein Link sieht aber allgemein sehr interessant aus. (Auch wenn der Designer der Seite keine Ahnung von Webdesign hat und ich bei 800x600 horizontal scrollen darf.)

Demnach tritt leider genau das ein, was ich schon schrieb. Die Applikation muß Side by Side unterstützen, was (mal wieder) zu einem Durcheinander führt. Das häufig die Problematik solcher Technologien, die später oder zu spät eingeführt werden. (Und nein, das ist nicht auf MS bezogen.)

Desweiteren kann ich mich noch an eine ältere Microsoft-Präsentation erinnern, in der stand/gesagt wurde, daß der Entwickler nicht auf Rückwärtskompatibilität achten müßte, auch nicht bei Minorversionen. Sehr schade, daß dem so ist, so können Applikationen nämlich weiterhin nicht von aktuallisierten Libraries profitieren. Hier wäre es schöner, klipp und klar zu definieren, wann eine Library rückwärtskompatibel sein muß und wann nicht. Aber das waren nur billige PPT-Folien (aber von MS), so daß die Information schlichtweg falsch oder unzureichend gewesen sein könnte.

Deinem Link nach lassen sich Shared Libs signieren. Ob das sinnvoll ist, weiß ich nicht so genau. Im Endeffekt lassen sich Libraries ja nur austauschen, wenn das Sicherheitssystem des Betriebssystems bereits versagt hat. Ob es da sinnvoll ist, Libraries zu signieren, wenn der Angreifer alternativ das komplette Programm oder Manifest austauschen kann, weiß ich nicht so. Nunja, ich bin in der Hinsicht aber nicht wissend genug, um es als Unsinnig abzutun, nur darüber nachdenken könnte man, finde ich. Grundsätzlich klingt Signierung aber erstmal nach etwas positivem.
Beachtlich finde ich, daß dynamische Applikationen dennoch relativ flott starten, wobei ich das nie gemessen oder geprüft habe, gegen wieviele dynamische Libs sie gelinkt sind.

 

@cirad

Die dll-hell wurde ja auf unterschiedliche Weise gelöst, wobei die Side-By-Side-Assembly-Komponente nur eine ist. Das an sich wichtigste Moment besteht darin, dass Anwendungen bei der Installation eben nicht mehr wie früher wild dlls im System(32)-Ordner ersetzen dürfen, sondern dann sofort die eigentliche MS-dll ins System zurückgebracht würde (Windows File Protection) .Programmierer sind also im Prinzip dazu gezwungen, dll-Varianten, die für ihre Applikationen notwendig sein sollten, im jeweiligen Programm-Ordner unterzubringen. Side-By-Side-Assembly stellt nun für die Fälle eine besondere Technik dar, in denen die eigentliche MS-Dll aus dem System32-Ordner ausgetauscht werden muss; aber eben nur für die Laufzeit des jeweiligen Programms.

Eine gute englischsprachige Erläuterung zur Problematik findet man hier :

http://www.msdnaa.net/Resources/Display.aspx?ResID=717

Kapitelüberschrift : Application Compatibility?Side-by-side Assemblies

 

ergänzung :

1. dot NET löst das dll problem(sag man zumindest,yuhuuu)
2. es gibt neben synaptic noch
aptitude

mfg

 

@franzkat:
Ich bin zwar nicht der Windows-Technologie-Geek, aber afaik funktioniert Side by Side nur bei entsprechenden Applikationen, die es auch nutzen, was zu einem ziemlichen Durcheinander führt. Das gleiche Problem wie mit der Multiuserfähigkeit.

Als Ergebnis können dann mehre DLL-Versionen auf einmal installiert werden, was allerhöchste Zeit wurde. Ein "Feature", was man ruhig schon vor 10 Jahren bei MS hätte haben können und sollen, hätte vieles erspart.

Im Endeffekt ein hochtrabender Begriff für etwas recht alltägliches. Ist halt wie Hyperthreating. Uralt,viele Hersteller nutzen es, Intel erfindet einen tollen neuen Namen und es wird entsprechend als neu verkauft. Klingt dumm, funktioniert aber prima. <:

Oder bietet mir Side by Side irgendetwas herausragendes, was man woanders nicht findet? (Ernst gemeinte Frage.)

@killermaster:
# This APT has Super Cow Powers.
Wie ich finde, das wichtigste Feature. *g*

 

benutze ich auch :-D (aber nur auf meinem debian mit X rechner )

mfg

 

@killermaster

Als notorischer Mausschubser nehme ich allerdings häufig synaptic, das ist ein grafisches Frontend für apt-get :

http://www.nongnu.org/synaptic/action.html

Inzwischen gibt's davon sogar schon die Version 0.47

 

APT-Get rulez

debian:/etc/rcS.d# apt-get
apt 0.5.4 for linux i386 compiled on Aug 19 2001 01:02:26
Usage: apt-get [options] command
apt-get [options] install|remove pkg1 [pkg2 ...]
apt-get [options] source pkg1 [pkg2 ...]

apt-get is a simple command line interface for downloading and
installing packages. The most frequently used commands are update
and install.

Commands:
update - Retrieve new lists of packages
upgrade - Perform an upgrade
install - Install new packages (pkg is libc6 not libc6.deb)
remove - Remove packages
source - Download source archives
build-dep - Configure build-dependencies for source packages
dist-upgrade - Distribution upgrade, see apt-get(8)
dselect-upgrade - Follow dselect selections
clean - Erase downloaded archive files
autoclean - Erase old downloaded archive files
check - Verify that there are no broken dependencies

Options:
-h This help text.
-q Loggable output - no progress indicator
-qq No output except for errors
-d Download only - do NOT install or unpack archives
-s No-act. Perform ordering simulation
-y Assume Yes to all queries and do not prompt
-f Attempt to continue if the integrity check fails
-m Attempt to continue if archives are unlocatable
-u Show a list of upgraded packages as well
-b Build the source package after fetching it
-c=? Read this configuration file
-o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
See the apt-get(8), sources.list(5) and apt.conf(5) manual
pages for more information and options.
This APT has Super Cow Powers.

:-D

mfg

 

Tja, das was bei Microsoft früher die dll-hell war, das ist bei einigen Linux-Distributionen der dependencies-jungle. Da lob ich mir eine Instrument wie apt-get, dass mir hilft, mich aus diesen Fallstricken zu befreien. Was MS anbetrifft : Man muss den Machern von XP lassen, dass sie das dll-Problem mit der Side-By-Side-Assemblies-Technologie gut in den Griff gekriegt haben.