Bitte erklärt mir das Linux-Paketsystem
Willkommen in der Mk-Community › Foren › Software › Linux/Unix › Bitte erklärt mir das Linux-Paketsystem
- Dieses Thema hat 16 Antworten und 9 Teilnehmer, und wurde zuletzt aktualisiert vor 16 Jahren, 10 Monaten von stimpy.
-
AutorBeiträge
-
-
13. Juni 2007 um 16:06 Uhr #483267stimpyTeilnehmer
Hallo zusammen,
einer der ganz wenigen Punkte, die mir an ubuntu (oder auch suse usw.) nicht so gut gefallen, ist das Paketsystem. Mir kommt das ganze schwerfällig und unübersichtlich vor, daher habe ich ein paar Fragen:
1. Warum setzt Linux auf ein Paketsystem? Was sind die Vorteile?
2. Unter Windows hat man zuweilen Ärger mit DLLs und Deinstallationen, aber man weiß immer welches Programm wo gespeichert ist. – Wohin werden Programme unter Linux installiert?
3. Was spricht gegen das ein-Programm-ein-Verzeichnis-System von DOS oder MAC-OS?
Habe schon versucht mich selbstständig zu informieren aber nix gefunden. – Sollte es wo anders gute Erklärungen geben, freu ich mich auch über einen Link oder ein gutes Suchwort.
-
13. Juni 2007 um 17:06 Uhr #686467flydieTeilnehmer
Die Programme werden in deinem Home Verzeichniss, in versteckten Verzeichnisse installiert (Ubuntu).
Das ist leider nicht richtig. Was da in den versteckten Ordnern und Dateien (mit einem Punkt vor dem Namen) gespeichert wird, sind die benutzerdefinierten Einstellungen.Ansonsten stimmt die Ausfuehrung von ulv.Ich quote hier mal Wikipedia:
Vorteile und NachteileMit einem Paketmanager vereinfacht sich die Installation eines Programms erheblich, da Programme nicht erst einzeln heruntergeladen, kompiliert und installiert werden müssen. Außerdem überwachen die meisten Paketmanager Konflikte zwischen Paketen mit gleichen Inhalten und verhindern so eine Systeminstabilität in dieser Beziehung.Ebenso ist das Löschen von Software deutlich vereinfacht: da der Paketmanager sich alle zu einem Paket gehörende Software merkt, kann bei einem Löschen eines Paketes sämtliche nicht mehr benötigte Software mit entfernt werden.
Gegen eine Installation wie man sie von Windows und OSX kennt, spricht unter anderem die Tatsache, dass viele Programme auf ein und dieselbe Bibliothek zugreifen wollen und diese sollte darum an einem definierten Ort liegen. Bei anderen Systemen werden die Bibliotheken bei Programmen, die sie nutzen, mitgeliefert. Das ist Platzverschwendung.Die Sache mit der $PATH Variable hat ulv ja schon angesprochen.Da OSX intern auch ein UNIX-aehnliches System ist, kommt hier auch so eine Verzeichnisstruktur zum Einsatz. Z.B. die Darvinports stellen hier ein Quellcodebasiertes Paketmanagement zur Verfuegung, das aehnlich funktioniert wie z.B. Portage bei Gentoo oder die Ports bei den *BSDs.Zudem gibt es den FHS an den sich die Distributoren weitestgehend halten:
Der Filesystem Hierarchy Standard (FHS) ist eine von der Filesystem Hierarchy Standard Group veröffentlichte Richtlinie, die Regeln über die Verzeichnisstruktur unter UNIX-ähnlichen Betriebssystemen festlegt.
Mir kommt das ganze schwerfällig und unübersichtlich vor
Tut mir leid aber das kann ich absolut nicht nachvollziehen. Wenn man sich in ein Paketmanagement eingearbeitet hat, ist es weder unuebersichtlich, schwerfaellig noch kompliziert. Man sollte sich nur mal die Muehe machen die Doku zu lesen.Als Alternative kannst du dir alle Programme, die du installieren willst runterladen, selbst kompilieren und auch die Abhaengigkeiten von Hand aufloesen. Mal schaun wie weit du da kommst.Allerdings gibt es bisher auch Ansaetze, die eine Installation wie z.B. .app bei OSX zu ermoeglichen. Ich halte das allerdings nicht fuer eine gute Idee.
-
13. Juni 2007 um 17:06 Uhr #686455Dr.TyfonTeilnehmer
1) Du kannst selbst entscheiden was du brauchst und was nicht. Dein PC wird so ganz dir angepasst.2,3) Die Programme werden in deinem Home Verzeichniss, in versteckten Verzeichnisse installiert (Ubuntu).
-
13. Juni 2007 um 17:06 Uhr #686468toorTeilnehmer
stimpy4ever said:
1. Warum setzt Linux auf ein Paketsystem? Was sind die Vorteile?Linux ist nur der Betriebssystemkern (Kernel). Ein Paketmanager sorgt für eine saubere Installation/Deinstallation sowie ein (im Idealfall) einfaches Aktualisieren der installierten Programme. Abhängigkeiten mit anderen Paketen und Konflikte zwischen einzelnen Paketen werden dabei ebenfalls berücksichtigt.
stimpy4ever said:
2. Unter Windows hat man zuweilen Ärger mit DLLs und Deinstallationen, aber man weiß immer welches Programm wo gespeichert ist. – Wohin werden Programme unter Linux installiert?In welchem Verzeichnis die Programme installiert werden hängt von der Distribution ab. Meistens aber in /usr/bin (da liegen aber normalerweise die Systemtools, zumindest bei FreeBSD ist das so) oder in /usr/local/bin. Manchmal wird das ganze aber auch einfach in /opt oder sonstwohin geklatscht 🙁
stimpy4ever said:
3. Was spricht gegen das ein-Programm-ein-Verzeichnis-System von DOS oder MAC-OS?Die ausführbaren Dateien liegen in /usr/local/bin (oder sonstwo, s.o.), der ganze Rest den die Programme zum funktionieren brauchen liegt anderswo auf der Platte. Was also ist der Vorteil wenn in jedem Verzeichnis nur eine ausführbare Datei liegt?
stimpy4ever said:
Habe schon versucht mich selbstständig zu informieren aber nix gefunden. – Sollte es wo anders gute Erklärungen geben, freu ich mich auch über einen Link oder ein gutes Suchwort.Wikipedia hat etliche Artikel zu Paketsystemen und Paketmanagern. Auf den Projektseiten der Distributionen wirst Du häufig auch fündig (in Form von HTML-Versionen der man-pages der Paketverwaltungswerkzeuge).Beispiele für Paketmanager (unvollständige Liste!):- PBI- rpm- pacman- APTund im weiteren Sinne:- Portage- FreeBSD ports- pkgsrc- OpenBSD ports/packagesHTH
OK, da waren andere schon schneller… -
13. Juni 2007 um 17:06 Uhr #686459tuxthekillerTeilnehmer
Linux hat kein Paketsystem. Allerdings haben die meisten Distributionen (wie Ubuntu, das auf Debian aufbaut) ein Paketsystem.Der Vorteil eines Paketsystems ist, das man nicht alle Programme von Hand installieren muss.”apt-get install -paket-” ist einfacher als:1. Paket downloaden2. Paket entpacken3. Paket compilern4. Paket installierenZudem werden auch die Abhängigkeiten installiert.Die Executables werden meist in /usr/bin/ gespeichert, Einstellungen usw. in /home/user.
-
13. Juni 2007 um 17:06 Uhr #686461ulvTeilnehmer
stimpy4ever;232307 said:
Hallo zusammen,einer der ganz wenigen Punkte, die mir an ubuntu (oder auch suse usw.) nicht so gut gefallen, ist das Paketsystem. Mir kommt das ganze schwerfällig und unübersichtlich vor, daher habe ich ein paar Fragen:
Das ist überhaupt nicht schwerfällig. Evtl. ein wenig gewöhnungsbedürftig.
stimpy4ever;232307 said:
1. Warum setzt Linux auf ein Paketsystem? Was sind die Vorteile?Vollständige Deinstallation von ALLEN Teilen eines Programms.
Updates von Programmen im laufenden Betrieb.
Und noch vieles mehr…stimpy4ever;232307 said:
2. Unter Windows hat man zuweilen Ärger mit DLLs und Deinstallationen, aber man weiß immer welches Programm wo gespeichert ist. – Wohin werden Programme unter Linux installiert?Windows:
Das, was du beschrieben hast ist ja wohl ein schlechter Witz! – Kennst dich mit Windows nicht so gut aus?Linux:
Programm nach /usr/bin oder /usr/sbin
Bibliotheken nach /usr/lib
Systemweite-Konfig nach /etc/und/oder /etc/default/ User-Konfig nach /home/ /. Startskripte nach /etc/init.d und Links dazu in /etc/rc*.d
Anleitungen nach /usr/share/doc/stimpy4ever;232307 said:
3. Was spricht gegen das ein-Programm-ein-Verzeichnis-System von DOS oder MAC-OS?z.B. DOS:
Die $PATH Variable (Suchpfad für ausführbare Programme) könnte man bei 20 Programmen nicht mehr schreiben – die war auf 256 Zeichen beschränkt.
Manche Teile will man sich ausdrücklich teilen z.B. Bibliotheken, Startmenues, Kontextmenues – alles was Windows wirr in der Registry verteilt. Manche Programme benötigen andere bevor sie starten können.
Jedes Programm (bei Windows) hat eine andere Ordnung in dem eigenen Verzeichnis. Das müsste man für jedes Programm neu lernen bzw. suchen.
Bei DOS: Das Chaos in Autoexec.bat und Config.sys.
Userverwaltung und Userrechte.
Ganz stimmen tut deine Aussage für DOS auch nicht, weil die ca. 200 DOS Befehle alle in einem Verzeichnis liegen. Es wurde unterschieden zwischen mitgelieferten und nachträglich installierten Programmen.
Linux macht diese Unterscheidung zum Glück nicht. Dadurch ist alles einheitlich und klar. Einmal lernen und man kennt sich immer aus. Nicht nur auf dem eigenen Rechner sondern überall. -
13. Juni 2007 um 19:06 Uhr #686496flydieTeilnehmer
stimpy4ever;232345 said:
Mh, was macht man denn wenn die in /usr/bin gemountete Festplatte voll ist?Was macht man wenn die Systemplatte voll ist? Ich Arbeite mit LVM und kann alle meine Partitionen (also alles bis auf /boot) dynamisch vergroessern wenn ich das brauche. Auch verkleinern ist drin, wenn es das verwendete Filesystem hergibt.
Ansonsten sind die installierten Pakete groessenmaessig meistens nur im ein bis zweistelligen MB-Bereich. Da sollte man halt vorher genug Platz einplanen.
Allerdings verbraucht mein Komplettes Linux-System weniger Platz als ein nackt installiertes WindowsXP. Also denke ich, dass ich damit leben kann.Allgemein ist es da problemloser als z.B. bei Windows. Nehmen wir mal an, dass die Root-Partition voll ist und man noch ne Partition frei hat:
- Verzeichnis suchen, dass man auf ne andere Partition mounten kann (z.B. /usr/)
- Parition temporaer mounten
- Daten umkopieren
- Daten im Ursprungsverzeichnis loeschen
- Partition als gewaehltes Verzeichnis mounten
- fertig
stimpy4ever;232345 said:
Also sind unter OSX die Programme doch nicht unabhänig und lassen sich nicht einfach so löschen und kopieren?Die Shellprogramme jedenfalls nicht, denn da ist es das selbe Prinzip wie bei GNU/Linux auch. Bei den Programmen, die man mit einer einzigen Datei installieren kann, geht das schon. Hier hat man halt wieder den erheblichen Nachteil, dass alles was das Programm an Libs etc. braucht in der datei enthalten sein muss. Das ist verdammt ineffizient.
stimpy4ever;232345 said:
Versteht mich bitte nicht falsch, ich find die ubuntu-Lösung besser als etwa die von MS. Aber ich fände es gut, wenn man kein System bräuchte das sich Abhängigkeiten merkt weil alle Programme unabhängig sind.Wie du durch die bisherigen Posts bemerkt haben solltest, ist dies technisch ziemlich unschoen. Und ich mal kurz nen Befehl absetze um ein Programm zu installieren und einen weiteren um es wieder sauber zu entfernen sollte wohl komfortabel genug sein.
Zugegeben ich sehe einen Punkt in dem das von Vorteil sein koennte: Bei der Verwendung von externen Datentraegern auf denen man die Programme liegen hat. Wenn man gewisse Programme auf nem USB-Stick liegen hat, waere das schon cool. Auf der anderen Seite kann man nen komplettes Linux auf nen Stick packen und von dem Stick booten.
Ich glaube allerdings, dass so Diskussionen eher fehl am Platz sind. Es ist prinzipiell Unsinn zu diskutieren “Warum $foo bei Linux nicht so funktioniert wie bei System $bar”. Es hat sich technisch so entwickelt und bisher funktioniert das ganze recht gut.
Falls jemand da anderer Meinung ist, kann er ja ein alternatives System zur Installation von Programmen entwickeln oder ein vorhandenes veraendern. Das ist doch das Schoene an OpenSource. -
13. Juni 2007 um 19:06 Uhr #686485stimpyTeilnehmer
Danke für eure Anworten, fühl mich schon wieder ein bisschen un-dummer.
Philipp said:
Linux ist nur der Betriebssystemkern (Kernel).I know, entschuldige die Ungenauigkeit.
Philipp said:
Wikipedia hat etliche Artikel zu Paketsystemen und Paketmanagern.Die Erklärungen dort fangen leider größtenteils erst da an, wo ich schon nichts mehr verstehe.
ulv said:
Programm nach /usr/bin oder /usr/sbin
Bibliotheken nach /usr/lib
Systemweite-Konfig nach /etc/und/oder /etc/default/ User-Konfig nach /home/ /. Startskripte nach /etc/init.d und Links dazu in /etc/rc*.d
Anleitungen nach /usr/share/doc/Mh, was macht man denn wenn die in /usr/bin gemountete Festplatte voll ist?
ulv said:
Das, was du beschrieben hast ist ja wohl ein schlechter Witz! – Kennst dich mit Windows nicht so gut aus?Oh doch! Schon untern Windows bin ich mit Firefox ins INet gegangen und hab die Registry mit Computerzeitschriften-Tipps getuned! – Bin also voll der Windows-Hacker! 😉
Aber ernsthaft, ich hätte wohl besser geschrieben: bei Windows weiß man z.T. wo die meisten Dateien eines Programms gespeichert sind. Einverstanden?pfleidi85 said:
Gegen eine Installation wie man sie von Windows und OSX kennt, spricht unter anderem die Tatsache, dass viele Programme auf ein und dieselbe Bibliothek zugreifen wollen und diese sollte darum an einem definierten Ort liegen.Also sind unter OSX die Programme doch nicht unabhänig und lassen sich nicht einfach so löschen und kopieren?
pfleidi85 said:
Mir kommt das ganze schwerfällig und unübersichtlich vor
Tut mir leid aber das kann ich absolut nicht nachvollziehen. Wenn man sich in ein Paketmanagement eingearbeitet hat, ist es weder unuebersichtlich, schwerfaellig noch kompliziert. Man sollte sich nur mal die Muehe machen die Doku zu lesen.
Versteht mich bitte nicht falsch, ich find die ubuntu-Lösung besser als etwa die von MS. Aber ich fände es gut, wenn man kein System bräuchte das sich Abhängigkeiten merkt weil alle Programme unabhängig sind. Wenn mir dann ein Kumpel ein paar Progs mitbringt, könnte ich sie einfach mal starten ohne sie ins System einbinden zu müssen. – Nur das alles selber von Hand machen klingt nach Overkill, besonders wenn es eigentlich nicht so gedacht ist hakt es später sicher irgendwo.
-
13. Juni 2007 um 21:06 Uhr #686527toorTeilnehmer
stimpy4ever said:
Philipp said:
Linux ist nur der Betriebssystemkern (Kernel).I know, entschuldige die Ungenauigkeit.
Na dann… Ich kann’s ja nicht wissen das Du weißt das es so ist wie es ist 😀
stimpy4ever said:
Philipp said:
Wikipedia hat etliche Artikel zu Paketsystemen und Paketmanagern.Die Erklärungen dort fangen leider größtenteils erst da an, wo ich schon nichts mehr verstehe.
Das ist ja nichts schlimmes. Wenn Du grundlegende Fragen hast, dann bemüh mal einschlägige Suchmaschinen oder frage hier (oder anderswo) nach. Es gibt sicherlich irgendjemand der Dir in irgendeiner Form weiterhelfen kann.
-
13. Juni 2007 um 21:06 Uhr #686521ulvTeilnehmer
stimpy4ever;232345 said:
Mh, was macht man denn wenn die in /usr/bin gemountete Festplatte voll ist?Für den Anfang würde ich alle Verzeichnisse in einer großen Partition lassen. Dann gibt es das Problem nicht. Mit der Zeit lernt man dann wie und warum es besser geht.
stimpy4ever;232345 said:
Oh doch! Schon untern Windows bin ich mit Firefox ins INet gegangen und hab die Registry mit Computerzeitschriften-Tipps getuned! – Bin also voll der Windows-Hacker! 😉
Aber ernsthaft, ich hätte wohl besser geschrieben: bei Windows weiß man z.T. wo die meisten Dateien eines Programms gespeichert sind. Einverstanden?Sorry, das beeindruckt mich jetzt noch garnicht.
Installier doch mal ein Programm auf die D: Platte und dann schau dir die HDD Lampe von C: an – dann bekommst du eine Ahnung, was ich meine 😀
Wenn die Hälfte der Daten auf D: liegt dann hast du schon Glück gehabt 😀
Wenn du mir dann erklären kannst warum man bei Windows eigentlich erst nach 3 mal booten Software endgültig fertig installiert hat dann reden wir nochmal.stimpy4ever;232345 said:
Versteht mich bitte nicht falsch, ich find die ubuntu-Lösung besser als etwa die von MS. Aber ich fände es gut, wenn man kein System bräuchte das sich Abhängigkeiten merkt weil alle Programme unabhängig sind. Wenn mir dann ein Kumpel ein paar Progs mitbringt, könnte ich sie einfach mal starten ohne sie ins System einbinden zu müssen. – Nur das alles selber von Hand machen klingt nach Overkill, besonders wenn es eigentlich nicht so gedacht ist hakt es später sicher irgendwo.Das geht schon mit Linux – für dich am einfachsten mit Gentoo.
Man kann alle Programme beim Kompilieren auch statisch gegen die Bibliotheken verlinken. Auch kommen die meißten Programme auch ohne Konfiguration aus bzw. man kann angeben wo die Konfig liegt.
Das ist das schöne an Linux: Es ist so wie es dir bzw. zu dir passt.Warum das von wenigen Ausnahmen nicht gut ist:
- Wie schon angesprochen braucht man dann viel (schätze etwa dreimal so viel) Platz auf der Platte.
- Wichtiger ist aber, dass wenn die Bibliothek im Arbeitsspeicher oder Cache vom Rechner ist, sie von mehreren Programmen gleichzeitig verwendet werden kann.
Das ist z.B. ein Grund, warum bei Linux nicht wie bei Windows die HDD immer rappelt – oder umgekehrt Linux auch mit weniger RAM noch gescheit läuft.
Die kleineren Programme sind also schneller geladen, laufen schneller und laufen auch auf schmaler Hardware.
Wenn du selber Software schreibst und statisch kompilierst kannst du die eine Datei deinem Freund geben, und dort läuft sie dann auch gleich. 😯
-
13. Juni 2007 um 22:06 Uhr #686536stimpyTeilnehmer
Philipp;232396 said:
Das ist ja nichts schlimmes. Wenn Du grundlegende Fragen hast, dann bemüh mal einschlägige Suchmaschinen oder frage hier (oder anderswo) nach. Es gibt sicherlich irgendjemand der Dir in irgendeiner Form weiterhelfen kann.Dank diverser Wikis, HowTo’s und schon vorhandener Threads hab ich bisher auch alles mit kubuntu hinbekommen, was ich wollte.
ulv;232388 said:
- Wie schon angesprochen braucht man dann viel (schätze etwa dreimal so viel) Platz auf der Platte.
- Wichtiger ist aber, dass wenn die Bibliothek im Arbeitsspeicher oder Cache vom Rechner ist, sie von mehreren Programmen gleichzeitig verwendet werden kann.
OK, dreimal so viel Platz ist heftig, hätte ich nicht erwartet und an den Arbeitsspeicher hatte ich noch gar nicht gedacht.
pfleidi85;232357 said:
stimpy4ever;232345 said:
Also sind unter OSX die Programme doch nicht unabhänig und lassen sich nicht einfach so löschen und kopieren?Die Shellprogramme jedenfalls nicht, denn da ist es das selbe Prinzip wie bei GNU/Linux auch. Bei den Programmen, die man mit einer einzigen Datei installieren kann, geht das schon. Hier hat man halt wieder den erheblichen Nachteil, dass alles was das Programm an Libs etc. braucht in der datei enthalten sein muss. Das ist verdammt ineffizient.
Ach so, das klingt schon anders als bei den Mac-Fans.
pfleidi85;232357 said:
Ich glaube allerdings, dass so Diskussionen eher fehl am Platz sind.Ich stimm dir voll zu, so Diskussionen in denen Wenig-Ahunung-Haber (wie ich) der Linux-Welt erklären wollen was Sache ist, sind selten sinnvoll. 😀
Ich denke der Thread hat seinen Zweck erfüllt. Ich verstehe jetzt Sinn und Vorteile der Paketverwaltung. – Danke für’s erklären! :d:
-
13. Juni 2007 um 23:06 Uhr #686554McTrevorTeilnehmer
Was mich an Linux am meisten beeindruckt, ganz ohne die ganzen technischen Details zu kennen, ist die Robustheit. Ich weiß noch, als ich Informatik-Student war und einer seine Linux-Kiste aufgehängt hatte. Dort bildete sich eine ungläubige Menschentraube.
Bei einem Windowsrechner hat man sowas übertrieben gesagt, zweimal die Woche.
Ein anderer Punkt ist die Installation. Bei einem heutigen Linux stopft man die CD rein und muss genau einmal rebooten. Im Gegensatz dazu bootet man bei Windows ja schon, wenn man die Schriftgröße ändert und übernehmen will.
Naja, ganz so krass ist es nicht, aber wenn man Windows XP inkl aller Treiber/Patches/ServicePacks installiert, hat man doch eine schöne Booterei vor sich. Unter Linux läuft das alles nebenher.
Bis dann denn!
McTrevor
-
14. Juni 2007 um 1:06 Uhr #686599drdopeTeilnehmer
stimpy4ever;232307 said:
Unter Windows hat man zuweilen Ärger mit DLLs und Deinstallationen, aber man weiß immer welches Programm wo gespeichert ist. – Wohin werden Programme unter Linux installiert?“equery” ist da z.B. sehr hilfreich (ist Gentoo-spezifisch, denke aber das andere Distros/Paketmanager über ähnliche Funtionen verfügen (sollten))
shockwave starscream # equery –helpUsage: equery
command where is one of -q, –quiet – minimal output -C, –nocolor – turn off colours -h, –help – this help screen -V, –version – display version info -N, –no-pipe – turn off pipe detectionwhere command(short) is one of belongs(b) files… – list all packages owning files… changes(c) – not implemented yet check(k) pkgspec – check MD5sums and timestamps of pkgspec’s files depends(d) pkgspec – list all direct dependencies matching pkgspec depgraph(g) pkgspec – display a dependency tree for pkgspec files(f) pkgspec – list files owned by pkgspec glsa(a) – not implemented yet hasuse(h) useflag – list all packages with useflag list(l) pkgspec – list all packages matching pkgspec size(s) pkgspec – print size of files contained in package pkgspec stats(t) – not implemented yet uses(u) pkgspec – display USE flags for pkgspec which(w) pkgspec – print full path to ebuild for package pkgspec Möchte ich z.B. wissen welche Dateien das Paket “mc” wo genau installiert hat,erfahre ich das mit:
shockwave starscream # equery f mc [ Searching for packages matching mc… ]* Contents of app-misc/mc-4.6.1-r3:/usr/usr/bin/usr/bin/mc/usr/bin/mcedit -> mc/usr/bin/mcmfmt/usr/bin/mcview -> mc/usr/lib64/usr/lib64/mc/usr/lib64/mc/cons.saver/usr/sbin/usr/share/usr/share/doc/usr/share/doc/mc-4.6.1-r3/usr/share/doc/mc-4.6.1-r3/AUTHORS.bz2/usr/share/doc/mc-4.6.1-r3/ChangeLog.bz2/usr/share/doc/mc-4.6.1-r3/FAQ.bz2/usr/share/doc/mc-4.6.1-r3/INSTALL.FAST.bz2/usr/share/doc/mc-4.6.1-r3/INSTALL.bz2/usr/share/doc/mc-4.6.1-r3/MAINTAINERS.bz2/usr/share/doc/mc-4.6.1-r3/NEWS.bz2/usr/share/doc/mc-4.6.1-r3/README.QNX.bz2/usr/share/doc/mc-4.6.1-r3/README.bz2/usr/share/locale/usr/share/locale/de/usr/share/locale/de/LC_MESSAGES/usr/share/locale/de/LC_MESSAGES/mc.mo/usr/share/man/usr/share/man/man1/usr/share/man/man1/mc.1.bz2/usr/share/man/man1/mcedit.1.bz2/usr/share/man/man1/mcview.1.bz2/usr/share/man/man8/usr/share/mc/usr/share/mc/bin/usr/share/mc/bin/mc-wrapper.csh/usr/share/mc/bin/mc-wrapper.sh/usr/share/mc/bin/mc.csh/usr/share/mc/bin/mc.sh/usr/share/mc/cedit.menu/usr/share/mc/edit.indent.rc/usr/share/mc/edit.spell.rc/usr/share/mc/extfs/usr/share/mc/extfs/README/usr/share/mc/extfs/a/usr/share/mc/extfs/apt/usr/share/mc/extfs/audio/usr/share/mc/extfs/bpp/usr/share/mc/extfs/deb/usr/share/mc/extfs/deba/usr/share/mc/extfs/debd/usr/share/mc/extfs/dpkg/usr/share/mc/extfs/extfs.ini/usr/share/mc/extfs/hp48/usr/share/mc/extfs/iso9660/usr/share/mc/extfs/lslR/usr/share/mc/extfs/mailfs/usr/share/mc/extfs/patchfs/usr/share/mc/extfs/rpm/usr/share/mc/extfs/rpms/usr/share/mc/extfs/sfs.ini/usr/share/mc/extfs/trpm/usr/share/mc/extfs/uar/usr/share/mc/extfs/uarj/usr/share/mc/extfs/uha/usr/share/mc/extfs/ulha/usr/share/mc/extfs/urar/usr/share/mc/extfs/uzip/usr/share/mc/extfs/uzoo/usr/share/mc/mc.charsets/usr/share/mc/mc.ext/usr/share/mc/mc.gentoo/usr/share/mc/mc.hint/usr/share/mc/mc.hint.cs/usr/share/mc/mc.hint.es/usr/share/mc/mc.hint.hu/usr/share/mc/mc.hint.it/usr/share/mc/mc.hint.nl/usr/share/mc/mc.hint.pl/usr/share/mc/mc.hint.ru/usr/share/mc/mc.hint.sr/usr/share/mc/mc.hint.uk/usr/share/mc/mc.hint.zh/usr/share/mc/mc.hlp/usr/share/mc/mc.ini/usr/share/mc/mc.lib/usr/share/mc/mc.menu/usr/share/mc/mc.menu.sr/usr/share/mc/syntax/usr/share/mc/syntax/Syntax/usr/share/mc/syntax/ada95.syntax/usr/share/mc/syntax/aspx.syntax/usr/share/mc/syntax/assembler.syntax/usr/share/mc/syntax/c.syntax/usr/share/mc/syntax/changelog.syntax/usr/share/mc/syntax/cs.syntax/usr/share/mc/syntax/diff.syntax/usr/share/mc/syntax/dos.syntax/usr/share/mc/syntax/ebuild.syntax/usr/share/mc/syntax/eiffel.syntax/usr/share/mc/syntax/fortran.syntax/usr/share/mc/syntax/html.syntax/usr/share/mc/syntax/idl.syntax/usr/share/mc/syntax/java.syntax/usr/share/mc/syntax/js.syntax/usr/share/mc/syntax/latex.syntax/usr/share/mc/syntax/lisp.syntax/usr/share/mc/syntax/lsm.syntax/usr/share/mc/syntax/lua.syntax/usr/share/mc/syntax/m4.syntax/usr/share/mc/syntax/mail.syntax/usr/share/mc/syntax/makefile.syntax/usr/share/mc/syntax/ml.syntax/usr/share/mc/syntax/nroff.syntax/usr/share/mc/syntax/octave.syntax/usr/share/mc/syntax/pascal.syntax/usr/share/mc/syntax/perl.syntax/usr/share/mc/syntax/php.syntax/usr/share/mc/syntax/po.syntax/usr/share/mc/syntax/povray.syntax/usr/share/mc/syntax/python.syntax/usr/share/mc/syntax/ruby.syntax/usr/share/mc/syntax/sh.syntax/usr/share/mc/syntax/slang.syntax/usr/share/mc/syntax/smalltalk.syntax/usr/share/mc/syntax/spec.syntax/usr/share/mc/syntax/sql.syntax/usr/share/mc/syntax/swig.syntax/usr/share/mc/syntax/syntax.syntax/usr/share/mc/syntax/tcl.syntax/usr/share/mc/syntax/texinfo.syntax/usr/share/mc/syntax/unknown.syntax/usr/share/mc/syntax/xml.syntax
Und das Beste zum Schluß–> Gentoo Linux Dokumentation — GentoolkitDazu gibts ne Doku!;)
-
17. Juni 2007 um 13:06 Uhr #687179stimpyTeilnehmer
Danke für den Tipp, drdope!
Wenn ich das richtig sehe, hat (k)ubuntu equery nicht übernommen. Man kann aber z.B. apt-get oder dpkg-www nutzen:
-
18. Juni 2007 um 12:06 Uhr #652516
-
18. Juni 2007 um 13:06 Uhr #650693toorTeilnehmer
borsti67 said:
Man sollte aber m.W. tunlichst die verschiedenen Paketverwaltungen nicht “mischen”. Also aptitude, apt-get oder was-auch-immer angucken, sich für eines entscheiden und dann dabei bleiben.Hab ich was verpasst? Ich dachte jede Distribution hätte ihr “ureigenes” Paketverwaltungssystem?
borsti67 said:
So hat man mir das jedenfalls nahegelegt. 😀Ja, das erscheint sinnvoll. Wer weiß was da angerichtet wird wenn n verschiedene Paketsysteme sich gegenseitig bei der Arbeit behindern 😀
-
18. Juni 2007 um 14:06 Uhr #648721ulvTeilnehmer
Philipp;233372 said:
Hab ich was verpasst? Ich dachte jede Distribution hätte ihr “ureigenes” Paketverwaltungssystem?Nun es gibt eine ganze Hirarchie: (ich kann das nur andeuten – ist nicht vollständig)
I) Die Pakete selbst
*.DEB Pakete
*.RPM Pakete
weitere Paketsorten siehe bei alien
(dazu kommt noch alien zum konvertieren der Pakete – nur für Fortgeschrittene!)II) Programme für unterschiedliche Anforderungen bzw. Abstraktionsebenen.
Für *.deb gibt es als Basis dpkg. Und …
Wikipedia said:
Auf dpkg aufbauende Softwaredpkg kann keine Abhängigkeiten auflösen oder Pakete aus dem Internet herunterladen. Es kann nur mit Dateien umgehen, die sich im Dateisystem befinden. Daher gibt es mehrere Programme, die diese Möglichkeiten ergänzen und auf dpkg aufbauen.
dselect kann selbständig Abhängigkeiten zwischen Paketen auflösen und Konflikte zwischen Paketversionen erkennen. Zum eigentlichen Installieren und Konfigurieren von Paketen kommt dpkg zum Einsatz. dselect kann Pakete aus diversen Quellen wie CDs, NFS- oder FTP-Servern beziehen. Dieses Frontend wurde ursprünglich von Ian Jackson entwickelt und war bis Debian 2.2 der bevorzugte Paketmanager.
Seit Debian 3.0 sind APT und Frontends dafür wie beispielsweise aptitude, apt-get und Synaptic die bevorzugten Werkzeuge zur Paketverwaltung. Auch dselect kann inzwischen die von APT angebotenen Mechanismen statt seiner eingebauten nutzen.
Für *.rpm gibt es rpm. Und …
Wikipedia said:
Programme, die RPM-Dateien verarbeiten [Bearbeiten]* urpmi von Mandriva, damit werden bei der Installation automatisch die Abhängigkeiten aufgelöst.
* apt4rpm – ein Port von APT für das RPM Format.
* up2date von RedHat
* kpackage
* gnorpm
* Yellowdog Updater, Modified
* YaST von SuSE enthält ein Modul zur Verwaltung von RPMs
* Smart Package Manager – dieses Werkzeug greift auf bestehende Werkzeuge (rpm, dpkg, …) zurück, und kann so auf vielen Distributionen eine einheitliche Oberfläche bietenIm Prinzip kann man die beliebig mischen, nur Backup, Restore, Clonen (auf andere Rechner) der Paketlisten sowie die Trennung in gewollte und nicht nötige Abhängigkeiten werden dann erschwert.
Im Ergebnis sammelt man durch das Mischen dann Pakete die man nicht (mehr) braucht und die einem manchmal im Weg sein können. 😀Für Anfänger ist ein einziges Tool sicher besser. Wobei ich ein relativ systemnahes Programm – auch wenn es Einarbeitung erfordert – wärmstens empfehlen kann. Sonst lernt man nichts und merkt auch nicht wenn man gerade etwas verbockt.
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.