ubuntuusers.de

Im Grunde wurden ja mit Version 1.0 alle apt- Programme in einem vereint und die Darstellung überarbeitet. Mir ist aufgefallen, dass diese Möglichkeit in keiner Vorlage berücksichtigt wird, obwohl sie mir persönlich eigentlich als am logischsten erscheint:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

$ apt --help
apt 1.3 (amd64)
Usage: apt [options] command

apt is a commandline package manager and provides commands for
searching and managing as well as querying information about packages.
It provides the same functionality as the specialized APT tools,
like apt-get and apt-cache, but enables options more suitable for
interactive use by default.

Meist benutzte Befehle:
  list - Pakete basierend auf dem Paketnamen auflisten
  search - Paketbeschreibungen durchsuchen
  show - Paketdetails anzeigen
  install - Pakete installieren
  remove - Pakete entfernen
  autoremove - alle nicht mehr verwendeten Pakete automatisch entfernen
  update - Liste verfügbarer Pakete aktualisieren
  upgrade - das System durch Installation/Aktualisierung der Pakete hochrüsten
  full-upgrade - das System durch Entfernung/Installation/Aktualisierung der Pakete vollständig hochrüsten
  edit-sources - die Datei für die Paketquellen bearbeiten

Siehe »apt(8)« für mehr Informationen über die verfügbaren Befehle.
Konfigurations-Optionen und -Syntax sind detailliert in »apt.conf(5)« aufgeführt.
Informationen zur Konfiguration der Quellen finden Sie in »sources.list(5)« .
Paket- und Versionsauswahlen können mittels »apt_preferences(5)« erfolgen.
Sicherheitsdetails sind verfügbar in »apt-secure(8)«.
                                     Dieses APT hat Super-Kuh-Kräfte.

Deshalb möchte ich vorschlagen, apt bei den Vorlagen der Paketlisten zum Kopieren hinzuzufügen und zum Standard zu machen, und aptitude und apt-get optional auswählbar zu lassen. Sobald der Support für Precise(→ Version 0.8.16) ausgelaufen ist, würde ich apt-get komplett streichen. Irgendwann wird der Befehl ja sicherlich auch gar nicht mehr funktionieren.

horstpenner schrieb:

Im Grunde wurden ja mit Version 1.0 alle apt- Programme in einem vereint und die Darstellung überarbeitet.

Mir scheint, dies ist ein Trugschluss.

SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
       The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward
       compatibility this is not guaranteed either if a change seems beneficial for interactive use.

       All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well.  apt(8) just changes the default value
       of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional
       options enabled) in your scripts as they keep backward compatibility as much as possible.

Es wurden also nur die Hauptanwendungen in das apt Werkzeug integriert und dazu gewisse Voreinstellungen angepasst. Der komplette Befehlsumfang steht nach wie vor in spezialisierten Werkzeugen wie apt-get oder apt-cache zur Verfügung.

Deshalb möchte ich vorschlagen, apt bei den Vorlagen der Paketlisten zum Kopieren hinzuzufügen

Hier weiß ich gerade nicht, was damit gemeint ist, das mag aber soweit in Ordnung sein.

und zum Standard zu machen, und aptitude und apt-get optional auswählbar zu lassen. Sobald der Support für Precise(→ Version 0.8.16) ausgelaufen ist, würde ich apt-get komplett streichen. Irgendwann wird der Befehl ja sicherlich auch gar nicht mehr funktionieren.

Das halte ich unter diesen Umständen für nicht angebracht.

OK, dass apt-get und apt-cache weiterhin bleiben, habe ich bisher nicht gewusst.

Dennoch bleibt ja, dass apt letztlich das Frontend für den User darstellen soll, wodurch ich es als Standard für deutlich besser halte.

Mit den Vorlagen meine ich:

• paket0

• paket1 (restricted)

Befehl zum Installieren der Pakete:

sudo apt-get install paket0 paket1 

Die Features, die apt-get und apt-cache zusätzlich zu bieten haben, braucht man im Wiki nie, und ein User braucht sie selbst auch nie. Es kommt die komfortable Änderung der Quellen hinzu:

sudo apt edit-sources

Dass man bei apt auf Rückwärtskompatibilität achtet, diese aber nicht gewährleisten kann, bedeutet nicht, dass die Befehle von apt-get und apt-search in Zement gegossen wären. Es ist zudem extrem unwahrscheinlich, dass diese elementaren Befehle irgendwann anders lauten. Ich sehe das Statement als reine Vorsichtsmaßnahme, wie "Dieses Produkt kann Spuren von Erdnüssen enthalten." 😉

horstpenner schrieb:

OK, dass apt-get und apt-cache weiterhin bleiben, habe ich bisher nicht gewusst.

Sie bleiben nicht nur erhalten, sie SIND die Anwendung.

Die Features, die apt-get und apt-cache zusätzlich zu bieten haben, braucht man im Wiki nie, und ein User braucht sie selbst auch nie.

Mit solchen Verallgemeinerungen wäre ich vorsichtig.

Nur weil der Großteil der hier zum Thema fragenden Nutzer sich offenbar nicht mit dem eigenen System beschäftigt heißt das nicht, dass dies "ein User" nicht brauchen würde.

Tausende von Usern schaffen es nämlich ihre Systeme durch die Nutzung von Dokumentationen (manpages, Wikis...) zu benutzen, nur das man das in einem Forum, wo hauptsächlich Nutzer mit häufig selbst kaum bis gar nicht selbst recherchierten Problemen aufschlagen, nicht sieht.

Und das beides im Wiki nicht benötigt werden würde widerlegen ja schon die dazu vorhandenen Artikel.

Z.B. wird gelegentlich ein --reinstall benötigt, wird aber von apt nur inoffiziell unterstützt.

tomtomtom schrieb:

Die Features, die apt-get und apt-cache zusätzlich zu bieten haben, braucht man im Wiki nie, und ein User braucht sie selbst auch nie.

Nur weil der Großteil der hier zum Thema fragenden Nutzer sich offenbar nicht mit dem eigenen System beschäftigt heißt das nicht, dass dies "ein User" nicht brauchen würde.

Wenn in der Vorlage standardmäßig apt statt apt-get stünde, würde das ja nicht bedeuten, dass man in Ausnahmefällen nicht das apt-get schreiben dürfte. Jetzt ist es ja auch schon inkonsistent, nur umgekehrt, durch den apt- Artikel.

Ich weiß noch, wie ich mich vor etwa 10 Jahren, als ich das erste mal diese Befehle eingetippt habe, tierisch darüber aufgeregt habe, dass man einen Bindestrich in einen Befehl macht, und vor allem, dass es 2 der Befehle gibt, obwohl die Argumente jeweils verschieden sind, diese Aufteilung also völlig unnötig ist. Es ist natürlich viel schwieriger, die Befehle im Kopf zu halten, als einfach nur apt für alles, was mit Paketverwaltung zu tun hat. Jetzt, wo das endlich beseitigt ist, verstehe ich nicht, warum man es den Leuten weiterhin so schwer macht.

Was --reinstall betrifft, sollte das auch mit remove package0 und install package0 möglich sein. Eine Vorlage, in der es vorkommt, existiert nicht, folglich würde alles, was bisher geschrieben steht, auch nicht tangiert werden. Wenn es also irgendwo mit apt-get --reinstall steht, kann es auch so bleiben.

Dieses Portal heißt ubuntuusers - fragen ist menschlich, und nicht Gentooenthusiasts - we are 1337. Leider kommt es mir manchmal so vor, als ob man das tatsächlich erwähnen müsste und wenn Ihr apt-get oder apt-cache standardmäßig benutzt, und apt selbst ignoriert, setzt Ihr Euch doch auch irgendwie über die Designentscheidungen der Apt- Entwickler hinweg, die apt explizit für User gemacht haben, und da nehme ich ubuntuusers mit ein.

horstpenner schrieb:

Wenn in der Vorlage standardmäßig apt statt apt-get stünde,

sind Nutzer von Ubuntu 12.04 und 14.04 ausgeschlossen. Damit darf ueber diesen Vorschlag gerne ab 2019 nochmal ernsthaft nachgedacht werden.

horstpenner schrieb:

Dieses Portal heißt ubuntuusers - fragen ist menschlich, und nicht Gentooenthusiasts - we are 1337.

Wo auch immer du da einen Zusammenhang mit dem Thema hier siehst...

Aber ja, users heißt, dass hier Nutzer unterwegs sind, keine System-Angucker. Und Nutzer können durchaus mit den vorhandenen Artikeln, die deiner Argumentation ja unnötig, weil nicht benötigt, sind, arbeiten. Wie geschrieben wohl nicht jeder, aber das ist nicht nur eine Frage des Verstehens sondern auch des Wollens.

aasche schrieb:

horstpenner schrieb:

Wenn in der Vorlage standardmäßig apt statt apt-get stünde,

sind Nutzer von Ubuntu 12.04 und 14.04 ausgeschlossen. Damit darf ueber diesen Vorschlag gerne ab 2019 nochmal ernsthaft nachgedacht werden.

Auf 14.04 ist Version 1.0.1. Nur 12.04- User müssten auf den apt-get- Hebel klicken. Auch wenn ich es als extrem vernachlässigendes Verhalten empfinde, die LTS- Versionen bis zum EOL auszufahren, könnte man ja apt zumindest hinzufügen, bis 12.04 in der Tonne ist.

Unter 14.04 empfiehlt das Terminal apt-get - für mich ein Grund, es somit auch weiterhin zu benutzen.

Unter 16.04 verwende ich nen Mischmasch - in meinen eigenen Vorlagen und im Wiki steht überall apt-get, wenn ich aber was eintippe oder Empfehlungen des Terminals einfach rauskopiere, dann wird apt benutzt.

Ob das irgendwann mal zu Komplikationen führen kann - keine Ahnung → das Thema beschäftigt mich aber auch immer mal wieder

Grüße

Frieder

Meiner Meinung nach sollte sich im Wiki eher auf apt-get bezogen werden, weil:

• es den kompleten Befehlsumfang zur Verfügugn stellt

• dort die vollständigen Optionen auch in den man-Pages angezeigt werden

Wenn jemand sich anhand des Wiki informiert/fortbildet, sollte er nicht mit apt auf ein nur begrenzt einsetzbares Werkzeug hingewiesen werden, da hier oft auch allgemeiner einsetzbare Grundlagen erarbeitet werden.

Wenn man hingegen im Forum antwortet, halte ich es durchaus für sinnvoll, nur apt zu benennen, weil sich das gerade für "Nur-Benutzer", die sich nicht um die Verwaltung des Systems kümmern wollen, sondern den Rechner einfach nur benutzen, einprägsamer ist. Man muss dann nicht wissen ob es "apt get install programm", "apt_get install programm" oder "apt-get install programm" heißen muss. "apt install programm" wirft weniger mnemonische Tücken auf.

horstpenner schrieb:

… Es kommt die komfortable Änderung der Quellen hinzu:

sudo apt edit-sources

Ob das komfortabel ist?

fs@xenial-m ~ $ sudo apt edit-sources

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.tiny

Choose 1-3 [2]: 2
fs@xenial-m ~ $ sudo nano /etc/apt/sources.list

Es macht sich im Forum vielleicht besser als für jede Desktop-Umgebung den passenden Texteditor zu nennen (leafpad, pluma, gedit, kate, …), aber kann ein „Mausschubser“ nano bedienen? Speichern mit Strg-O, verlassen mit Strg-X. Da hat man schneller erklärt, wie man für die grafische Variante root-Rechte erlangt.

Richtig toll wird es aber, und da muss ich dann Recht geben, wenn man weitere Dateien im Verzeichnis sources.list.d hat. Da spart man deutlich beim Tippen:

sudo apt edit-sources userdefined.list
sudo nano /etc/apt/sources.list.d/userdefined.list

Was mich an apt noch stört, ist so eine Meldung, die in verschiedenen Szenarien auftaucht, z. B.

apt list --installed > ~/Schreibtisch/liste
apt list --installed | grep -v 'lokal'

das führt unweigerlich zu

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Wenn ich die Ausgabe einer harmlosen Liste nicht umleiten oder durchsuchen kann, dann greife ich doch lieber auf altbewährte Mittel zurück bis apt ausgereifter ist.

ed an erster Stelle hat auf jeden Fall etwas, müsste nur noch als Vorauswahl gesetzt sein.😉

Aber stimmt ja, das ist natürlich DER Standardeditor.

Die rudimentäre Bedienung von nano ist doch aber im Programm selbst angezeigt.

Welcher Anfänger tippt denn noch im Terminal? Ich fast nix. Das meiste erledigt die Tab-Taste. Wen interessieren da noch lange Dateipfade?

lionlizard schrieb:

Meiner Meinung nach sollte sich im Wiki eher auf apt-get bezogen werden,[...] Wenn man hingegen im Forum antwortet, halte ich es durchaus für sinnvoll, nur apt zu benennen

Das würde jetzt schon deutlich mehr Sinn machen. Ich finde es jedenfalls ein Stück weit wichtig, dass eine Konsistenz da ist. Ich persönlich wäre deshalb dafür, apt im Wiki, wie auch im Forum möglichst immer zu verwenden, damit eine absolute Konsistenz da ist, und man apt-get wirklich nur dann liest, wenn es absolut nötig ist, weil der Befehl durch apt ausnahmsweise nicht abgedeckt wird.

Für Programme, die auf APT zugreifen, ist natürlich auch apt-get die logische Schnittstelle.

Ich kann schon nachvollziehen, wo der Haken ist. Irgendwie ist ja die automatisch generierte Liste keine Eingabe, die der User auf dem Terminal selbstbestimmt Buchstabe für Buchstabe macht. Sondern er kopiert einfach etwas ab. Andererseits hängt er ja trotzdem dazwischen, und ich habe auch schon oft solche Listen abgetippt, wenn sie nicht lang waren. Ein Programm, was automatisiert auf ein anderes zugreift, ist es also auch wieder nicht. Der User bekommt so immer wieder zu Gesicht, was eigentlich nicht das Interface ist, was auf ihn zugeschnitten ist, bekommt beispielsweise eventuell Lösungshinweise bei Fehlermeldungen nicht, etc. So hat er halt zusätzlich trotzdem noch beide Varianten irgendwie im Kopf.

Edit: Benno-007 schrieb:

Welcher Anfänger tippt denn noch im Terminal? Ich fast nix. Das meiste erledigt die Tab-Taste. Wen interessieren da noch lange Dateipfade?

Ich denke nicht, dass die Tipparbeit das Problem ist, auch wenn ich sudo gedit sources.list eingebe, passiert auf TAB nichts. Ich muss also den ganzen Pfad kennen, ob ich nun per TAB vervollständige oder nicht. Mit sudo apt edit-sources ist das nicht nötig. Ab dem zweiten Mal wird direkt der einmalig festgelegte Editor gestartet. Nano kann nun wirklich jedes Kind bedienen, was lesen kann.