Das mit Synaptic ist leider keine Lösung, denn blöderweise zeichnet Synaptic nur die eigenen Aktivitäten auf, und selbst wenn man es schafft, nur Synaptic zum installieren zu benutzen, dann sieht man in dieser Chronik nicht, welche Pakete man selber ausgewählt hat und welche Pakete Synaptic dazu als Abhängigkeit ausgewählt hat.
Manuell installierte Pakete auflisten
![]() Anmeldungsdatum: Beiträge: 134 |
|
||
Anmeldungsdatum: Beiträge: 77 |
aptitude merkt sich welche Pakete automatisch installiert wurden. aptitude show eog Paket: eog Zustand: Installiert Automatisch installiert: ja Version: 2.24.3.1-1 Priorität: optional Bereich: gnome Verwalter: Guilherme de S. Pastore <gpastore@debian.org> Unkomprimierte Größe: 6402k [...] dpkg hingegen hat keine Möglichkeit darauf zuzugreifen. dpkg -s eog Package: eog Status: install ok installed Priority: optional Section: gnome Installed-Size: 6252 Maintainer: Guilherme de S. Pastore <gpastore@debian.org> Architecture: amd64 Version: 2.24.3.1-1 [...] Vergleicht man das mit z.B. gimp aptitude show gimp Paket: gimp Zustand: Installiert Automatisch installiert: nein Version: 2.6.6-1 Priorität: optional Bereich: graphics Verwalter: Ari Pollak <ari@debian.org> [...] dpkg -s gimp Package: gimp Status: install ok installed Priority: optional Section: graphics Installed-Size: 13480 Maintainer: Ari Pollak <ari@debian.org> Architecture: amd64 Version: 2.6.6-1 [...] Die Ausgabe von dpkg -s zeigt nicht mehr an, ob ein Paket automatisch installiert wurde oder nicht. /var/lib/aptitude/packagestates 104454 Package: gimp 104455 Unseen: no 104456 State: 1 104457 Dselect-State: 1 104458 Remove-Reason: 0 75663 Package: eog 75664 Unseen: no 75665 State: 1 75666 Dselect-State: 1 75667 Remove-Reason: 4 Woher weiß aptitude nun, welches Paket automatisch installiert wurde und welches nicht? |
||
![]() Anmeldungsdatum: Beiträge: 134 |
keine Ahnung, fände ich auch sehr interessant. Aber das ist ja cool! Aptitude scheint das für alle Pakete korrekt zu wissen, auch wenn es die gar nicht selber installiert hat. Ich habe jetzt mal mein Skript so verändert, dass es den Aptitude Status nimmt. Folgendes geht nur mit der deutschen version von aptitude, da es die Textausgabe von Aptitude auswertet: ❗ DATUM anpassen oder wenn alle Pakete durchsucht werden sollen, vor Zeile 9 eine Raute (#) einfügen und vor Zeile 12 entfernen.
Das script braucht deutlich länger (mindestens faktor 5) als das vorher gepostete. Das Ergebnis ist aber besser. Es findet bei mir ca halbsoviele Pakete. Es scheint keins zu fehlen, und ich zweifle nur bei ganz wenigen daran, dass ich sie selber ausgewählt habe. |
||
Anmeldungsdatum: Beiträge: 77 |
Das Skript läuft unzumutbar lange. Es läuft nun schon 5 Minuten. Aptitude beherrscht auch die Möglichkeit mehrere Paketnamen auf einmal als Argument zu übergeben. Ein Skript müsste sowas machen wie alle installierten Pakete an aptitude show zu übergeben, dann nach Automatisch installiert: nein suchen und das Paket 2 Zeilen darüber ausgeben. Mir fehlen leider die Skills um sowas zu bewerkstelligen ☹ |
||
![]() Anmeldungsdatum: Beiträge: 953 |
Bei meinem Debian-System läuft das 2. Skript 25min und gibt mehr Programme aus als die 1. Version, nämlich 333. Ich lasse jetzt den Gegentest laufen, und schaue, bei wievielen Programmen ja statt nein steht. So, fertig: 732 Pakete. Das erste Skript hingegen gibt 154 Pakete aus. |
||
![]() Anmeldungsdatum: Beiträge: 134 |
Jetzt hatte ich gerade ein Skript fertig, was aptitude auf die gleiche weise wie das letzte benutzt, aber alle argumente auf einmal übergibt, und dann den gesamten output parst, aber dann habe ich entdeckt, dass aptitude sich ja ganz gut parametrisieren lässt. Der folgende Befehl gibt eine liste der nicht-automatisch installierten Pakete: aptitude -F %p search "?and(?installed,?not(?automatic))" Allerdings sind auch viele Pakete, die während der Installation von (K)ubuntu installiert worden als nicht-automatisch markiert. Wenn man ungefähr weiss, wann die (K)ubuntu Installation fertig war, kann man mit dem Python Skript im Anhang diese Pakete herausnehmen. Das Skript kann man z.B. so benutzen (natürlich vorher ausführbar machen und so): amanplist --date="2009-04-01 23:42" -o packages.list Ich wundere mich immernoch, dass das funktioniert, obwohl ich Aptitude nie zum Installieren von Paketen benutzt habe. Ich habe keine Ahnung wie sicher dieser automatisch-installiert Status ist. Außerdem fehlt noch eine Methode um herauszubekommen, wann die Installation von Ubuntu fertig war, damit das Script das Datum selber einsetzten kann. Hat jemand ne Ahnung? |
||
![]() Anmeldungsdatum: Beiträge: 192 |
Hi, ich verfolge schon ne ganze Weile sehr gespannt den Thread. So ne Liste brauch ich auch!
Ich hab noch folgendes Problem festgestellt: Vielleicht hat ja noch jemand ne zündende Idee, wie man die Standardpakete rausnehmen kann. Gibt es nicht irgendwo (vll. packages.ubuntu.com) ne Liste, wo man die Pakete her bekommen kann, die bei einer Installation installiert werden? Es grüßt, |
||
![]() Anmeldungsdatum: Beiträge: 953 |
grunsch schrieb:
Man könnte die Abhängigkeit einiger Meta-Paketen mit der Liste abgleichen: (k|x)ubuntu-desktop, ubuntu-minimal Damit dürften eine Reihe von Paketen wegfallen. |
||
![]() Anmeldungsdatum: Beiträge: 134 |
stancil schrieb:
Anscheinend aus dieser Datei hier: /var/lib/apt/extended_states Da steht drin, welches Paket automatisch installiert wurde. Aber nicht welche explizit installiert wurden. Nur bei Paketen, die irgendwann mal automatisch installiert wurden und dann aber nochmal explizit zur Installation angefordert wurden, steht ein "Auto-Installed: 0" Das Auge schrieb:
Ja, einige fallen dann weg, aber ich glaube, das installationsprogramm installiert noch mehr. Und das ist glaube ich auch noch abhängig von der verwendeten Architektur, Hardware und Sprache. Cool wäre eine Möglichkeit, die Installation von einer Ubuntu CD ganz normal zu starten, und nachdem man alles ausgewählt hat, drückt man nicht OK sondern fängt die zur Installation generierte Paketliste ab. |
||
![]() Anmeldungsdatum: Beiträge: 454 Wohnort: Norddeutschland |
Bin glaube ich auf ne bessere Lösung gestoßen: Ich unterscheide ob per DVD oder online eingespielt. for pkg in $(COLUMNS=200 dpkg -l | awk '/^ii/{print $2}'); do echo "$pkg $(apt-cache policy $pkg | grep -FA1 '***' | tail -1 | awk '{print $2, $3}')" ; done > package.list gibt dann ne Liste a la xserver-xorg-video-vesa http://de.archive.ubuntu.com jaunty/main jaunty/main heißt in meinem Fall von der DVD grep -v "jaunty/main" gibt also alle die nicht von DVD also online reingekommen sind cut -d ' ' -f 1 <liste.blabla.lst gibt dann die 1. Spalte sprich eine Liste der Packetnamen xarg apt-get rappelt den ganzen kram dann rein cu |
||
Anmeldungsdatum: Beiträge: 8 |
freunde, ich kann nicht programmieren. suche daher immer ganz - manchmal viel zu - einfache lösungen: kann man nicht ein system frisch aufsetzen, von dvd, und dann mit --get-selections eine originalliste erstellen, dann pakete einspielen ohne ende, und danach nochmal eine paketliste machen lassen und die zwei dann mit DIFF oder so was vergleichen lassen? oder die 1. liste einfach von der dvd auslesen und dann mit diff o.ä. vergleichen lassen? oder noch einfacher: auf den servern liegen doch die paketlisten eh aus von den downloadversionen, und den ist-zustand damit vergleichen ? lg, seltenheit. |
||
![]() Anmeldungsdatum: Beiträge: 953 |
Das Hauptproblem sehe ich darin, dass ich eine Paketliste haben möchte mit jenen Programmen, die installiert wurden, weil ich sie ausgewählt habe, aber ohne jene Programme, die dadurch zusätzlich auf die Festplatte kamen, also die Abhängigkeiten der manuell installierten Pakete. Dann kann ich die Paketliste auch noch in zwei Jahren verwenden, mit Ubuntu 13.10, ohne Angst haben zu müssen, dass sich die Abhängigkeiten geändert haben, und ich mir einen Haufen Schrott installiere. Ich habe jedenfalls kein gutes Gefühl dabei, Bibliotheken von Hand zu installieren, bei denen ich nicht mehr weiß, ob sie noch gebraucht werden, und wofür sie gut sind. Außerdem funktioniert dann apt-get purge nicht mehr. |
||
Anmeldungsdatum: Beiträge: 8 |
verstehe, klingt echt kompliziert so... ich machs nun anders: bin von ubuntu / bzw. mint auf ubuntu-basis auf lmde gewechselt, also die linux-mint rolling debian-distribution mit mint-look-n-feel, also die verschmelzung aus effizienz und schönheit: NIE MEHR ein neues system aufsetzen müssen! und mit - code apt-get autoremove - code - u.ä. mitteln einfach den ballast loswerden, falls er das nicht automatisch macht. zudem habe ich eine eigene datenpartition, was auf linuxmintusers immer wieder statt einer separaten /home empfohlen wird. so können die pakete konfigurieren, was sie wollen, aber das wird bei einem neuen system davon einfach getrennt gehalten, weil die versteckten config-dateien der programme im home auf der / - part. bleiben. basta. m.e. die beste lösung für alle, die öfter mal ein neues BS ausprobieren. (musste nur FF und TB im profilmanager umlinken, einmalig.) fertig ☺ wäre das nix für dich? lg |
||
Anmeldungsdatum: Beiträge: 8 |
"Unentschlossen schwankt | mein Herz in Sorge bangt nach KDE verlangt | obwohl Kubuntu krankt. Doch wohin soll es gehen? Vielleicht zu openSUSE mit allerletzem Gruße zurück zu apt-get sehn?" hmm...: entschlossen geh voran mit mint, dein sorgen schießt sich in den wind. es debian als basis nimmt, wichtig bleibt: die mischung stimmt. ☺ ps: (aua.) |