einer von 5 Leuten aus dem Security-Team sind gewechselt. Das traurige ist nur, dass das einer von 3 war, die in den letzten Jahren auch was gemacht haben...
full ack! Verwerft rpm oder die rpm-basierten Distris stellen apt4rpm oder das Gentoo oder BSD Port System bereit. Ob rpm besser als dpkg ist, sei dahin gestellt, jedoch fehlt es an einem Tool, welches die Abhängigkeiten selbständig auflöst bzw. die fehlenden Pakete einfach aus dem Internet nachinstalliert. Seien wir mal ehrlich, alles andere hat doch wirklich keinen Zopf Gruß
Es fehlt an keinem Tool, das Abhängigkeiten auflösen kann. SUSE hat YaST, Fedora yum, Mandriva urpmi. Außerdem kann man bei allen APT nachinstallieren, wenn man unbedingt apt-get install amarok statt urpmi amarok schreiben will.
nur das zumindest yast nicht wirklich echt toll mit den Abhängigkeiten klarkommt: Pakete werden auf gesperrt gesetzt, ohne daß man es weiß, bei Installation von Fremdpaketen (packman) gibt es plötzlich lauter Konflikte wenn man ein suse update macht, teilweise tauchen Pakete nicht mehr in der Datenbank auf, obwohl man die Programme im Menü wunderbar starten kann, manuell auf "hold" gesetzte Pakete werden trotzdem aktualisiert ... yast ist ein wirklich schlechtes Beispiel, mit yum und urpmi habe ich noch nicht viel gemacht, aber yast war definitiv einer der Gründe, weshalb ich zu *.deb gegangen bin. Wobei auch bei *.deb nicht alles Gold ist, was glänzt: kann ich nicht einfach ein gebrochenes Paket auf dem System behalten, weil von mir aus die libpng0 die falsche Version hat, das Programm aber trotzdem funktioniert??? Die Info nehme ich ja gerne zur Kenntnis ...
Dein Problem hat nichts mit dpkg oder deb zu tun, sondern mit APT. APT verweigert grundsätzlich die Mitarbeit, sobald die Paketverwaltung inkonsistent ist. Man muss dann via apt-get -f install die Konsistenz wiederherstellen, was natürlich ne Deinstallation der libpng0 zur Folge haben wird.
Das ist im Übrigen ein Vorteil von urpmi. Das arbeitet auch dann noch weiter, wenn man ein Paket per rpm --nodeps installiert hatte. Man kann sogar urpmi selbst dazu überreden, Abhängigkeiten nur soweit möglich aufzulösen und dann die Pakete zu installieren, selbst wenn ne Abhängigkeit fehlt. Das wäre für ne Installation von KDE auf Debian vor 2(?) Jahren auch sinnvoll gewesen, als wegen libsensors KDE nicht installierbar war, die man ja nur für ksensors brauchte.
Das wäre ein _wirklich_ wichtiges feature. Vieleicht geht es ja irgendwie, falls ja bitte mir sagen ! Wenn ich z.B. ein Programm wie den Open Office Kde Quickstarter installieren will, dann verlangt apt immer libqt/kdelibs/kdebase usw. Nur hab ich alles selber compiliert (qt und kde). Das bedeutet das alle Pakete mit Abhängigkeit auf kde oder qt für mich völlig nutzlos sind, obwohl ich fast alles mit kde Programmen mache weil ich den Desktop und das drum herum so mag.
Total OT, aber... ich liebte die DLD!!!! Mein lieblingsbefehl: dldadmin! Wunderbar!
Nun zum Topic: nachdem Debian ja schon fast als Dinosaurier betrachtet wurde, der bald aussterben wird, scheint dies ja die Auferstehung des Phönix zu sein. Debian wohin man schaut. Ubuntu-Feeling... Linux ist teilweise schon spannender als manches Länderspiel!
Nun, für Tüftler wird es immer Alternativen geben, aber um Firmen dazu zu bewegen, mehr Software für Linux zu schreiben, und sei es closed source, muss es eben Einheitlicher werden. Flexibilität muss sein, das ist ein grosser Vorteil von Linux, aber auf der anderen Seite muss es auch distributionsübergreifende Standards geben, sonst driftet alles auseinander und keinem ist geholfen. Ich kann es nur nachvollziehen hier Synergien nutzen zu wollen, schliesslich will alles bezahlt werden.
Ach, deswegen verwendet Mandriva statt des freedesktop.org-Standards ein 100% proprietäres Menü, das Ähnlichkeiten mit dem proprietären Debian-Menü hat (/usr/lib/menu statt /usr/share/applications) und unvorhersagbare Namenskonventionen für Pakete, damit auch bloß niemand vorher wissen kann, wie der Name eines Originalprogramms nun auf den Namen eines Mandriva- oder Debian-Pakets abzubilden ist (z.B. libgtk+2.0 statt gtk2, auf BiArch-Plattformen sogar besonders extrem: lib64gtk+2.0 statt gtk2). Aber das Gerücht, dass eine sehr bekannte ehemals deutsche Distribution "ein eigenes Süppchen bei Dateipfaden kocht", ist trotzdem nicht aus der Welt zu bekommen, dabei hält sich diese Distribution an Namenskonventionen und verwendet Standardmenüs...
FUD? Ich hatte nie einen solchen Vorfall, bin mir aber sicher, dass jegliche Häme über derartige sicher irgendwann mal vorgekommene Vorfälle unangebracht sind, weil sich mit Google bestimmt ähnliche Vorfälle finden lassen werden.
Auch SUSE verwendet für 64 Bit-Libs Zusätze im Paketnamen. Anderenfalls könnte man gar nicht nur die 32- oder 64-Bit Variante deinstallieren.
Und dass die Lib-Pakete so benannt werden, hat seine Gründe und Vorteile. Nur so können unterschiedliche binärinkompatible Libs parallel installiert werden.
Beispiel FLAC: Hier wurde von 1.1.0 auf 1.1.1 mal eben die Lib von libflac.so.4 auf libflac.so.6 umbenannt. Es fand also ein API-Wechsel statt. Wenn das Paket nun nur flac heißt, kann nur entweder die Lib mit Majorversion 4 oder 6 installiert sein. Hat man Anwendungen, die gegen die eine, und welche, die gegen die andere Version der Lib gelinkt sind, hat man dann ein Problem. Man kann leider auch nicht einfach das eine Paket über das andere installieren, da in diesem Fall die Binaries flac und metaflac überschrieben werden, und man so die alten erhält, wenn man das alte Paket nachträglich installiert.
Bei manchen Paketen bieten SUSE und Co. daher compat-Pakete an. Die Lösung finde ich allerdings nicht so toll, da man nicht erkennt, welche Versionen jetzt alle da drin stecken.
Nicht ganz, SuSE und Fedora benennen RPMs immer genau so wie den Original-Tarball, es sei denn, es sind tatsächlich mehrere Versionen auf der Distribution. Dann wird der unterscheidende Teil der Versionsnummer an den Namen angehängt, also gtk und gtk2. 64-Bit-Versionen heißen auf BiArch-Systemen genauso, wenn es zusätzlich eine 32-Bit-Version gibt, wird -32bit an den Paketnamen angehängt.
Die ausschließlich von Mandriva verwendete abweichende Namenskonvention ist nicht per se schlecht, hat aber den gewaltigen Nachteil, dass die Vorhersagbarkeit der Paketnamen wirklich stark eingeschränkt ist. Deswegen ist es nicht selbstverständlich, dass RedHat-RPMs laufen - ich gehe davon aus, dass die das über massiven Gebrauch des Provides-Tags umgehen.
Mandriva wird sich da schon was dabei gedacht haben, allerdings wäre es auch nicht ganz verkehrt gewesen, es einfach "wie die anderen" zu machen - Detailverbesserungen kann man ja immer noch machen. Die Parallelinstallation inkompatibler Bibliotheken ist ja wirklich eher die Ausnahme, ich habe ehrlich gesagt höchstens eine Handvoll davon auf meinem System, ist das wirklich ein Thema?
Stimmt, es waren die 32-Bit-Libs. Sie heißen also in 32- und 64-Bit Variante nicht gleich. Nebenbei sind laut FHS auf AMD64 die 32-Bit Libs diejenigen, die in /usr/lib landen sollen und die 64-Bit Libs gehören nach /usr/lib64. Das erklärt die Vorgehensweise von Mandriva.
SUSE und Fedora benennen die Pakete NICHT genau nach dem Tarball. Oder wie erklärst du es dir, dass das Paket mit der Qt 3.x mal qt und mal qt3 heißt? Ich weiß grad nur nicht, ob Fedora oder SUSE die 3 gestrichen hatte.
Die abweichende Namenskonvention wird auch von den Debian-basierten Distributionen verwendet.
Natürlich ist die Parallelinstallation eher die Ausnahme, aber SUSE und Fedora machen es fast unmöglich, sie parallel zu installieren, ohne Paketinkonsistenzen zu provozieren (mehrere Pakete mit identischen Namen, eine Datei in mehreren Paketen, ...), die man mit --force umgehen muss, um die Pakete überhaupt gleichzeitig installieren zu können. Zudem nennen die Distributionen sie unterschiedlich. Fedora nennt das Paket mit der OpenSSL 0.9.6 Bibliothek openssl096, wie es SUSE nennt, weiß ich grad nicht. Wenn nun ein Paket von openssl = 0.9.6 abhängt, haut das nicht hin, da das Paket nun anders heißt. Natürlich kann man auch da einiges über Provides machen, aber warum nennen nicht alle Distributoren ihre Pakete so, dass sie diese nicht nachträglich umbenennen müssen?
Ich fände es jedenfalls gut, wenn Red Hat und SUSE sich bei Bibliotheken an Debian oder Mandriva orientieren würden. Das würde auch Updates erleichtern, da die neue Distroversion nicht unbedingt alle Pakete der alten Version weiterführt und man so noch die der alten weiternutzen könnte, die von Paketen abhängt, die aktualisiert wurden und die in der neuen Version binär inkompatibel zur alten sind.
Ich habe mir vor kurzem das ein Notebook Medion md 95500 gekauft!!! FOLGENDE HARDWARE: NVIDIA6600go, Realtec 880D(SOUND),usw...
Habe fast alle Distris probiert wie z.B. Mandrake 10,1/10.2 Suse 9.1/9.2/9.3 Fedora 2/3, Ubuntu, Knoppix 3,9, Kanottix usw.usw.... ICH SAGE EUCH ES IST MISST!!! Keine einzige Distri konnte ich unter diesem Notebook installieren!!! Susew 9,3 tat es aber kein Sound. Konnte die NVIDIA treiber nicht installieren weil es einfach bei der Installation hängen blieb!!! Die Installation von Suse konnte nur mit Acpi Disabled erfolgen sonst blieb es immer hängen. Ich weis es nicht es werden keine treiber für linux geschrieben weil jede Linux Version anders ist z.B. andere packete benutzt usw usw.....
Soll ich mir deswegen jetzt ein anderes Laptop anschaffen????????????????????
Ich sehe es nicht ein!!!!!!!!! Linux sollte so sein das es unter allen Laptops und Desktop Systemen läuft. LÄUFT LEIDER NICHT UND WIRD AUCH NIE LAUFEN!!! Ich muss nicht Programiersprachen studieren und selber Treiber schreiben!!! Ich bin richtig verärgert dass Die meisten Sound Karten, Wlan geräte, usw... nicht unter LINUX laufen!!! Mann muss wirklich studieren um vieles zum laufen zu bringen. ES tut mir leid aber Linux ist und wird auch niemals ein Desktop System werden!!! Dazu hat es viel zu viele macken!!!
Bevor man sowas kauft, sollte man sich informieren, ob's für das gewünschte Betriebssystem auch die passenden Treiber gibt (sofern man die Dinger nicht selbst programmieren will!!). Ich kaufe mir ja auch kein Apple Computer und bin dann maßlos enttäuscht, daß sich Windoof nicht installieren läßt. Und von Hardware, bei der sich die Hersteller zu fein dafür sind, auch nur die geringsten Informationen dem willigen kostenlos arbeitenden Programmiervieh bereitzustellen, sollte man sowieso die Finger davon lassen. Ich tippe mal, daß WindoofYR ohne spezielle Herstellertreiber auf der Kiste auch keine Freude bereitet und der Sound auch für ruhige Klosteratmosphäre sorgt.
Alle Debian Maintainer sind zu Ubuntu gewechselt...
Hast du dich vertippt?
ob Mandriva dann auf lange Sicht weiterhin eine rpm- basierte Privatkundenversion anbieten wird?
Gruß,
Bernhard
Verwerft rpm oder die rpm-basierten Distris stellen apt4rpm oder das Gentoo oder BSD Port System bereit. Ob rpm besser als dpkg ist, sei dahin gestellt, jedoch fehlt es an einem Tool, welches die Abhängigkeiten selbständig auflöst bzw. die fehlenden Pakete einfach aus dem Internet nachinstalliert. Seien wir mal ehrlich, alles andere hat doch wirklich keinen Zopf
Gruß
SUSE hat YaST, Fedora yum, Mandriva urpmi.
Außerdem kann man bei allen APT nachinstallieren, wenn man unbedingt apt-get install amarok statt urpmi amarok schreiben will.
.
Das ist im Übrigen ein Vorteil von urpmi. Das arbeitet auch dann noch weiter, wenn man ein Paket per rpm --nodeps installiert hatte. Man kann sogar urpmi selbst dazu überreden, Abhängigkeiten nur soweit möglich aufzulösen und dann die Pakete zu installieren, selbst wenn ne Abhängigkeit fehlt. Das wäre für ne Installation von KDE auf Debian vor 2(?) Jahren auch sinnvoll gewesen, als wegen libsensors KDE nicht installierbar war, die man ja nur für ksensors brauchte.
Das bedeutet das alle Pakete mit Abhängigkeit auf kde oder qt für mich völlig nutzlos sind, obwohl ich fast alles mit kde Programmen mache weil ich den Desktop und das drum herum so mag.
Felix
Zuerst fanden RedHat und die DLD zusammen.
Das mit UnitedLinux war bei SuSE in der Zeit, als sie noch nicht mit Novell und Ximian verschmolzen waren.
Mandrake und Connectiva verbindeten sich zu Mandriva. Linspire will auch dazustoßen.
Scheinbar wird der große Markt der vielen Linux-Distributionen kleiner. Und viele kleine verbinden sich zu wenig großen.
Nur OpenLinux von Caldera (jetzt SCO Group) will keiner mehr haben.
Beweis: Geh mal auf www.delix.de
Delix war der Distributor der DLD.
Mein lieblingsbefehl: dldadmin! Wunderbar!
Nun zum Topic: nachdem Debian ja schon fast als Dinosaurier betrachtet wurde, der bald aussterben wird, scheint dies ja die Auferstehung des Phönix zu sein. Debian wohin man schaut.
Ubuntu-Feeling...
Linux ist teilweise schon spannender als manches Länderspiel!
CU
Dirk
Und dass die Lib-Pakete so benannt werden, hat seine Gründe und Vorteile. Nur so können unterschiedliche binärinkompatible Libs parallel installiert werden.
Beispiel FLAC: Hier wurde von 1.1.0 auf 1.1.1 mal eben die Lib von libflac.so.4 auf libflac.so.6 umbenannt. Es fand also ein API-Wechsel statt. Wenn das Paket nun nur flac heißt, kann nur entweder die Lib mit Majorversion 4 oder 6 installiert sein. Hat man Anwendungen, die gegen die eine, und welche, die gegen die andere Version der Lib gelinkt sind, hat man dann ein Problem.
Man kann leider auch nicht einfach das eine Paket über das andere installieren, da in diesem Fall die Binaries flac und metaflac überschrieben werden, und man so die alten erhält, wenn man das alte Paket nachträglich installiert.
Bei manchen Paketen bieten SUSE und Co. daher compat-Pakete an. Die Lösung finde ich allerdings nicht so toll, da man nicht erkennt, welche Versionen jetzt alle da drin stecken.
Die ausschließlich von Mandriva verwendete abweichende Namenskonvention ist nicht per se schlecht, hat aber den gewaltigen Nachteil, dass die Vorhersagbarkeit der Paketnamen wirklich stark eingeschränkt ist. Deswegen ist es nicht selbstverständlich, dass RedHat-RPMs laufen - ich gehe davon aus, dass die das über massiven Gebrauch des Provides-Tags umgehen.
Mandriva wird sich da schon was dabei gedacht haben, allerdings wäre es auch nicht ganz verkehrt gewesen, es einfach "wie die anderen" zu machen - Detailverbesserungen kann man ja immer noch machen. Die Parallelinstallation inkompatibler Bibliotheken ist ja wirklich eher die Ausnahme, ich habe ehrlich gesagt höchstens eine Handvoll davon auf meinem System, ist das wirklich ein Thema?
Nebenbei sind laut FHS auf AMD64 die 32-Bit
Libs diejenigen, die in /usr/lib landen sollen und die 64-Bit Libs gehören nach /usr/lib64. Das erklärt die Vorgehensweise von Mandriva.
SUSE und Fedora benennen die Pakete NICHT genau nach dem Tarball. Oder wie erklärst du es dir, dass das Paket mit der Qt 3.x mal qt und mal qt3 heißt? Ich weiß grad nur nicht, ob Fedora oder SUSE die 3 gestrichen hatte.
Die abweichende Namenskonvention wird auch von den Debian-basierten Distributionen verwendet.
Natürlich ist die Parallelinstallation eher die Ausnahme, aber SUSE und Fedora machen es fast unmöglich, sie parallel zu installieren, ohne Paketinkonsistenzen zu provozieren (mehrere Pakete mit identischen Namen, eine Datei in mehreren Paketen, ...), die man mit --force umgehen muss, um die Pakete überhaupt gleichzeitig installieren zu können.
Zudem nennen die Distributionen sie unterschiedlich. Fedora nennt das Paket mit der OpenSSL 0.9.6 Bibliothek openssl096, wie es SUSE nennt, weiß ich grad nicht. Wenn nun ein Paket von openssl = 0.9.6 abhängt, haut das nicht hin, da das Paket nun anders heißt. Natürlich kann man auch da einiges über Provides machen, aber warum nennen nicht alle Distributoren ihre Pakete so, dass sie diese nicht nachträglich umbenennen müssen?
Ich fände es jedenfalls gut, wenn Red Hat und SUSE sich bei Bibliotheken an Debian oder Mandriva orientieren würden. Das würde auch Updates erleichtern, da die neue Distroversion nicht unbedingt alle Pakete der alten Version weiterführt und man so noch die der alten weiternutzen könnte, die von Paketen abhängt, die aktualisiert wurden und die in der neuen Version binär inkompatibel zur alten sind.
So ein Quatsch. Lern erstmal was 'proprietaer' heisst.
http://de.wikipedia.org/wiki/Propriet%C3%A4r
Danke
Und Mandrake war schon öfter für Überraschungen gut. Insofern finde ich das alles zwar sonderbar, aber nicht total abwegig.
berichtet darüber. Eher Gerücht, als Tatsache.
Just my flat.
Nix für ungut...
Habe fast alle Distris probiert wie z.B. Mandrake 10,1/10.2 Suse 9.1/9.2/9.3 Fedora 2/3, Ubuntu, Knoppix 3,9, Kanottix usw.usw.... ICH SAGE EUCH ES IST MISST!!! Keine einzige Distri konnte ich unter diesem Notebook installieren!!! Susew 9,3 tat es aber kein Sound. Konnte die NVIDIA treiber nicht installieren weil es einfach bei der Installation hängen blieb!!! Die Installation von Suse konnte nur mit Acpi Disabled erfolgen sonst blieb es immer hängen. Ich weis es nicht es werden keine treiber für linux geschrieben weil jede Linux Version anders ist z.B. andere packete benutzt usw usw.....
Soll ich mir deswegen jetzt ein anderes Laptop anschaffen????????????????????
Ich sehe es nicht ein!!!!!!!!! Linux sollte so sein das es unter allen Laptops und Desktop Systemen läuft. LÄUFT LEIDER NICHT UND WIRD AUCH NIE LAUFEN!!! Ich muss nicht Programiersprachen studieren und selber Treiber schreiben!!! Ich bin richtig verärgert dass Die meisten Sound Karten, Wlan geräte, usw... nicht unter LINUX laufen!!! Mann muss wirklich studieren um vieles zum laufen zu bringen. ES tut mir leid aber Linux ist und wird auch niemals ein Desktop System werden!!! Dazu hat es viel zu viele macken!!!
Ich kaufe mir ja auch kein Apple Computer und bin dann maßlos enttäuscht, daß sich Windoof nicht installieren läßt.
Und von Hardware, bei der sich die Hersteller zu fein dafür sind, auch nur die geringsten Informationen dem willigen kostenlos arbeitenden Programmiervieh bereitzustellen, sollte man sowieso die Finger davon lassen.
Ich tippe mal, daß WindoofYR ohne spezielle Herstellertreiber auf der Kiste auch keine Freude bereitet und der Sound auch für ruhige Klosteratmosphäre sorgt.
mfg