ubuntuusers.de

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.

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?

Woher weiß aptitude nun, welches Paket automatisch installiert wurde und welches nicht?

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

#!/bin/bash

## Pakete, die nach diesem Datum installiert wurden durchsuchen:
DATUM="2009-04-28 17:00"

## Genau eine der folgenden Zeilen, die mit PACKAGELIST beginnen muss auskommentiert sein:

## Pakete seit bestimmtem Datum durchsuchen:
PACKAGELIST=`find /var/lib/dpkg/info/ \( -newermt "$DATUM" -name \*.list \) | sed 's#.list$##;s#.*/##'`

## Alle Pakete durchsuchen:
#PACKAGELIST=`dpkg-query -W -f='${Package}\n'`

for PACKAGE in $PACKAGELIST
do
        if aptitude show $PACKAGE |grep -q "Automatisch installiert: nein"; then
                echo "$PACKAGE"
        fi
done

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.

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 ☹

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.

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?

Hi,

ich verfolge schon ne ganze Weile sehr gespannt den Thread. So ne Liste brauch ich auch! Ich hab noch folgendes Problem festgestellt:
Ich habe diesmal ein Update gemacht, deswegen sind die beim Update installierten Pakete jünger als die, die ich vor dem Update manuell installiert habe und der Datumstrick klappt nicht so recht...

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,
der Grunsch

grunsch schrieb:

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?

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.

stancil schrieb:

Woher weiß aptitude nun, welches Paket automatisch installiert wurde und welches nicht?

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:

grunsch schrieb:

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?

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.

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.

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

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.

seltenheit schrieb:

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?

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.

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

"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.)