staging.inyokaproject.org

kaputtnik schrieb:

• Das mit der grafischen Oberfläche sollte eingebaut werden

aber bitte mit einem deutlichen Warnhinweis, lies Dir bitte die Paketbeschreibung dazu durch

Hallo,

interessant wäre noch, ob Maverick-Server aptitude dabei hat. Lucid-Server hat es definitiv.

Leider habe ich selber kein Zeit, Maverick-Server mal schnell zu installieren...

Gruß, nosiefloor

Bei Ubuntu wird Atitude noch im Bereich admin aufgeführt.

Kann es sein das da irgendwie ein Fehler von Ubuntu vorliegt, das das nicht mehr zur Standardinstallation gehört? Oder gehören nicht alle Pakete aus admin zu einer Standardinstallation?

Hallo,

Oder gehören nicht alle Pakete aus admin zu einer Standardinstallation?

Nein, bei Weitem nicht.

Gruß, noisefloor

auch heise 🇩🇪 hat was dazu im Testbericht:

Dafür haben die Entwickler Aptitude, das mächtigste Werkzeug für die Softwareverwaltung auf der Kommandozeile, aus der Standardinstallation entfernt; lediglich das ältere apt-get ist installiert. Unverständlich, ist doch laut den Machern der Ubuntu-Grundlage Debian aptitude das empfohlene Frontend zur Paketverwaltung.

Thread dazu auf der Ubuntu-devel-Mailingliste.

aptitude bleibt in der Serverversion im Standardrepertoire.

Hallo,

habe einen Hinweis eingebaut.

Gruß, noisefloor

Ich denke folgende Textpassage verwirrt nur:

Mit dem Erscheinen von Debian Etch 4.0 im April 2007 ist aptitude die „bevorzugte“ Paketverwaltung von Debian und tritt damit die Nachfolge von dselect und apt an.

Vielleicht sollte man das ändern, indem man das ganze in die Vergangenheit setzt und dann direkt dahinter schreibt:

Seit Ubuntu 10.10 Maverick Meerkat wird aptitude aus Platzgründen nicht mehr automatisch auf dem Desktop mit installiert. ?

Was denkt ihr?

LG Ernie

Danke für den Vorschlag, ich habe es mal entsprechend umgesetzt und hoffe, das es nun verständlicher ist.

Gruß
kaputtnik

Der Teil Tags vergeben stimmt so meiner Meinung nach nicht. Laut dem aptitude Benutzerhandbuch entfernt remove-user-tag einen Tag von einem Paket, aber nicht das Paket selbst. Statt

sudo aptitude remove-user-tag '?user-tag(freeorionkompilierung)' 

müsste es meiner Meinung nach also

sudo aptitude remove '?user-tag(freeorionkompilierung)' 

heißen. Dieser Befehl entfernt nämlich die mit freeorionkompilierung getaggten Pakete. Ich habe es zumindest gerade eben genau so gehandhabt.

Mit

sudo aptitude add-user-tag '?user-tag(Usertag)' Paketname

und

sudo aptitude remove-user-tag '?user-tag(Usertag)' Paketname

kann man den User-Tag Usertag zum Paket „Paketname“ hinzufügen bzw. entfernen.

Ich weiß nicht, ob ich einfach so in dem Artikel herumpfuschen kann. Wenn dem so ist und hier keiner gegenteilige Argumente vorbringen kann, werde ich das ändern.

Hat sich keiner gemeldet → ich hab's geändert.

Wollt grad mal das automatische Update Script aus dem Artikel ausprobieren und dabei sagt er mir dass "upgrade" veraltet ist, stattdessen sollte man "safe-upgrade" verwenden - Schlage vor das im Artikel zu ändern.

NoNeed schrieb:

Schlage vor das im Artikel zu ändern.

Auch hier gilt: Wer Fehler findet, darf sie verbessern. 😉

Im Abschnitt "Paketzustand speichern oder wiederherstellen" steht ein sudo vor dem aptitude-run-state-bundle. Das klingt zwar logisch, scheint aber nicht zu funktionieren. Zumindest bekam ich unterschiedliche Resultate, ob ich es mit oder ohne sudo startete. Ohne sudo hat's funktioniert (nachdem ich dann innerhalb von aptitude zum root wurde). Mit sudo konnte ich meinen alten Systemstand nicht wiederherstellen. Kann das jemand nachvollziehen? Dann würde ich es ändern 😉

Pienz

Hallo,

bei mir kam bei der Erstellung des Paketzustandes schon Fehler:

~$ aptitude-create-state-bundle paketzustand
tar: .//var/lib/apt/lists/lock: Kann open nicht ausführen: Keine Berechtigung
tar: .//etc/apt/trustdb.gpg: Kann open nicht ausführen: Keine Berechtigung
tar: .//etc/apt/secring.gpg: Kann open nicht ausführen: Keine Berechtigung
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Wie war das bei Dir?

Wenn man create-state-bundle per sudo ausführt und danach run-state-bundle per sudo ausführt wird nach kurzer Zeit aptitude gestartet, was auch normal ist.

Auf jeden Fall gehört ein sudo auch vor den ersten Befehl zur Speicherung des Paketzustandes.

Der Artikel ist aber hier ziemlich ungenau. So wie ich das sehe wird durch create-state-bundle eine tar-Archiv angelegt, welches bestimmte Dateien enthält. Anders wie im Artikel angegeben werden durch run-state-bundle die Dateien aber nicht an den ursprünglichen Platz zurück geschrieben, sondern in ein temporäres Verzeichnis und anschließned ein Programm (in der Regel aptitude selber) aufgerufen, welches dann die Dateien des temporären Verzeichnisses verwendet.

Man aptitude-run-state-bundle:

 aptitude-run-state-bundle unpacks the given aptitude state bundle created by aptitude-create-state-bundle(1) to a temporary directory,
       invokes <program> on it with the supplied <arguments>, and removes the temporary directory afterwards. If <program> is not supplied,
       it defaults to aptitude(8).

Es ist also nicht so, dass hiermit der Paketzustand (blödes Wort) des Systems wieder hergestellt werden kann.

Gruß
kaputtnik