'apt' - Fragen, Erkennen und Verstehen ??

[KP97]

...den Versionsnamen des aktuellen Debian-Stable in der Sources-List zusammen mit
#su -
#apt update && apt full-upgrade
#apt autoremove && sudo apt clean

@rocky
OT, ist mir aber aufgefallen:
Was bezweckst Du denn mit sudo apt clean, wenn Du doch vorher schon mit su - zum Root geworden bist? Doppelt hält besser? ;-)

Ich hätte wirklich nicht gedacht, daß ein einfacher Befehl und eine ausführliche Manpage fünf Seiten im Thread produzieren kann...

[reox]

Vor welchen undokumentierten Kommandos in apt schützen uns die manpage und --help denn sonst noch, um uns "nicht mit einem Überfluss an Optionen und Einzelheiten zu überwältigen"?

Naja eigentlich gar nicht viel mehr. Wenn man den Source anschaut sieht man, dass die undokumentierten Befehle wie dist-upgrade dort nur noch des Muskelgedächtnisses wegen dabei sind: https://salsa.debian.org/apt-team/apt/- ... ine/apt.cc

Das hidden gem ist wohl

Code: Alles auswählen

$ apt moo
                 (__)
                 (oo)
           /------\/
          / |    ||
         *  /\---/\
            ~~   ~~
..."Have you mooed today?"...

(oder hätt ich das nicht hier verraten dürfen? )

[Blue]

@KP97, bezüglich "#apt autoremove && sudo apt clean":

@rocky
OT, ist mir aber aufgefallen:
Was bezweckst Du denn mit sudo apt clean, wenn Du doch vorher schon mit su - zum Root geworden bist? Doppelt hält besser?

Das ist ganz einfach ein Tippfehler. Ich habe den Text nicht meinem aktuellen Root-Bashrc-Alias (#alias u='apt update && apt full-upgrade' sowie #alias c='apt autoremove && apt clean') entnommen, sondern einer alten eigenen Anleitungsdatei.

"Sudo" hatte ich in meinen Ubuntu-Zeiten ( ) verwendet, "apt-get" ist imho nur noch für Grufties...

Beeiindruckt bin ich - und das meine ich mit vollem Ernst, ohne jegliche Ironie - dass Du die Posts offensichtlich sehr genau liest!

Ich hätte wirklich nicht gedacht, daß ein einfacher Befehl und eine ausführliche Manpage fünf Seiten im Thread produzieren kann...

Noch dazu - um es freundlich zu formulieren - mit erheblicher Redundanz.

[Blue]

Vor welchen undokumentierten Kommandos in apt schützen uns die manpage und --help denn sonst noch, um uns "nicht mit einem Überfluss an Optionen und Einzelheiten zu überwältigen"?

Naja eigentlich gar nicht viel mehr. Wenn man den Source anschaut sieht man, dass die undokumentierten Befehle wie dist-upgrade dort nur noch des Muskelgedächtnisses wegen dabei sind: https://salsa.debian.org/apt-team/apt/- ... ine/apt.cc

Das hidden gem ist wohl

Code: Alles auswählen

$ apt moo
                 (__)
                 (oo)
           /------\/
          / |    ||
         *  /\---/\
            ~~   ~~
..."Have you mooed today?"...

(oder hätt ich das nicht hier verraten dürfen? )

Dieser Befehl (#apt moo) fehlt auch im Manual!
Und eigentlich müßte es ein Gnu (= afrikanische Kuhantilope) statt eine Kuh sein!!!

(oder hätt ich das nicht hier verraten dürfen? )

Als Whistleblowing geht das wohl nicht durch.

Und ich oute noch mehr :
https://www.reddit.com/r/linuxmemes/com ... i/apt_moo/
https://unix.stackexchange.com/question ... cow-powers
https://wiki.ubuntuusers.de/Easter_Eggs/
https://www.digitalocean.com/community/ ... aster-eggs
Uuund: cowsay !

[Meillo]

Wenn man den Source anschaut sieht man, dass die undokumentierten Befehle wie dist-upgrade dort nur noch des Muskelgedächtnisses wegen dabei sind: https://salsa.debian.org/apt-team/apt/- ... ine/apt.cc

Besonders nett ist, dass die Funktion im Code dennoch DoDistUpgrade heisst.
https://salsa.debian.org/apt-team/apt/- ... apt.cc#L76

[whiizy]

Naja eigentlich gar nicht viel mehr.

Nette Funde, sehr amüsant!
Die apt manpage verrät uns 13 Kommandos. Die apt --help schützt uns noch etwas besser mit nur 12 Kommandos. Weggelassen wurde purge.

Dank Open Source sehen wir auf den ersten Blick zumindest schonmal 29 Kommandos, das sind immerhin mindestens 123% mehr, als in der manpage.

Am meisten vermisse ich in den Listen aber die explizite Erwähnung des Kommandos apt --simulate bzw. --dry-run. Für mich eines der wichtigsten Kommandos von apt-get überhaupt. Für Fortgeschrittene ebenso, wie für leichtsinnige Anfänger, um sich ein System nicht gleich kaputtzudaten. Funktioniert zum Glück aber auch in apt weiterhin. Habe ich aber auch nur über mein Muskelgedächtnis gemerkt

Code: Alles auswählen

man apt
-------
update
upgrade
full-upgrade
install
reinstall
remove
purge
autoremove
satisfy
search
show
list
edit-sources

apt --help
----------
list
search
show
install
reinstall
remove
autoremove
update
upgrade
full-upgrade
edit-sources
satisfy

apt.cc
------
list
search
show
install
reinstall
remove
autoremove
auto-remove
autopurge
purge
update
upgrade
full-upgrade
edit-sources
moo
satisfy
dist-upgrade
showsrc
depends
rdepends
policy
build-dep
clean
autoclean
auto-clean
source
download
changelog
info   

Grüsse und ein dreifaches Moo!

[tscott]

Ich hätte wirklich nicht gedacht, daß ein einfacher Befehl und eine ausführliche Manpage fünf Seiten im Thread produzieren kann...

Noch dazu - um es freundlich zu formulieren - mit erheblicher Redundanz.

Das stimmt, Redundanz ist drin. Aber auch immer wieder neue Erkenntnisse. Die Manpage gibt das genaue Verhalten von 'apt full-update' nicht annähernd wieder. Warum wird was wann gelöscht? Wie wird versucht Abhängigkeitsprobleme zu lösen?
Ich verstehe die Diskussion daher als Brainstorming in Erweiterung zur Manpage.

[whiizy]

Was ich auch nicht so ganz verstehe, wieso apt hinter -s keine TAB-Ergänzung anbietet, bei der Langform --simulate aber schon:

Code: Alles auswählen

# apt -s dist[TAB]

# apt --simulate dist[TAB]-upgrade 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Der Befehl apt-get macht hingegen die TAB-Ergänzung noch in beiden Schreibweisen. - Oder macht apt das zufällig nur in meinem Terminal so?

[Meillo]

Was ich auch nicht so ganz verstehe, wieso apt hinter -s keine TAB-Ergänzung anbietet, bei der Langform --simulate aber schon:

Die Tab-Completion ist eine frei programmierbare Erweiterung der Shell. Sie wird normalerweise als Datei von dem Anwendungspaket (hier apt bzw. apt-get) geliefert. Wenn deren Entwickler etwas vergessen haben, dann fehlt die Completion dafuer halt.

D.h. im Gegensatz zur Tab-Completion fuer Kommandos, die generisch anhand von $PATH umgesetzt werden kann, ist die Tab-Completion fuer Optionen und Parameter eines Kommandos nur eine Datei, die die Kombinationen in einer speziellen Sprache auflistet. Diese ist von den Entwicklern geschrieben. Hier ist die Datei von Unstable:
https://sources.debian.org/src/apt/2.3. ... /bash/apt/

Wenn hier etwas fehlt, das da sein sollte, dann waere das ein Grund fuer einen Bugreport (von niedrigerer Prioritaet). Allerdings kann ich deine Aussage anhand der Completion-Datei nicht nachvollziehen. `-s' und `--simulate' stehen immer paarweise in der Datei.

[whiizy]

Vielen Dank für die ausführliche Erläuterung, Meillo!

Dann ist es vielleicht nur ein kleiner Bug von apt in Bullseye, hier:

Code: Alles auswählen

# apt -v
apt 2.2.4 (amd64)

Dein Listing bezieht sich ja schon auf apt 2.3.14.

Wenn sich das am Listing nicht nachvollziehen lässt -- kannst du es denn praktisch an der Kommandozeile nachvollziehen?

[Blue]

Ich hätte wirklich nicht gedacht, daß ein einfacher Befehl und eine ausführliche Manpage fünf Seiten im Thread produzieren kann...

Noch dazu - um es freundlich zu formulieren - mit erheblicher Redundanz.

Das stimmt, Redundanz ist drin. Aber auch immer wieder neue Erkenntnisse. Die Manpage gibt das genaue Verhalten von 'apt full-update' nicht annähernd wieder. Warum wird was wann gelöscht? Wie wird versucht Abhängigkeitsprobleme zu lösen?
Ich verstehe die Diskussion daher als Brainstorming in Erweiterung zur Manpage.

Ehrlich gesagt habe ich bisher die Manpages fast gar nicht zu Rate gezogen.
Etwas bequemer lassen sie sich übrigens mit helpman lesen.
Wenn ich etwas wissen wollte, habe ich die "wiki.ubuntuusers" ( https://wiki.ubuntuusers.de/Startseite/ ) aufgesucht, weil dort Grundlagen seriös aber dennoch verständlich dargestellt werden.
An Sonsten verwende ich Debian-Stable ja gerade deshalb, weil die Upgrades dort imho die sichersten der Linux-Welt sind.
Will sagen, ich bin mit Debian-Stable ein glücklicher No-Brainer.

[dasebastian]

Vor welchen undokumentierten Kommandos in apt schützen uns die manpage und --help denn sonst noch, um uns "nicht mit einem Überfluss an Optionen und Einzelheiten zu überwältigen"?

Es ist zwar in der apt.cc Liste nebenbei aufgetaucht, ich werfe es trotzdem nochmals ausdrücklich rein:

Code: Alles auswählen

apt autopurge

Für die ganz Wilden unter uns...

[Meillo]

Dann ist es vielleicht nur ein kleiner Bug von apt in Bullseye, hier:

Code: Alles auswählen

# apt -v
apt 2.2.4 (amd64)

Dein Listing bezieht sich ja schon auf apt 2.3.14.

Ich hatte mir auch die Completion von deiner Version angeschaut. In keiner der beiden ist mir etwas aufgefallen. Allerdings kenne ich mich mit diesen Dateien auch nicht aus. Ich habe bloss nach `-s' und `--simulate' gesucht und keine Unterschiede gefunden.

Wenn sich das am Listing nicht nachvollziehen lässt -- kannst du es denn praktisch an der Kommandozeile nachvollziehen?

Nein. Das sieht alles in Ordnung aus. Ich habe keine Ahnung woran das liegen koennte. Das muesste sich jemand anschauen, der sich technisch damit auskennt.

Wenn du das Verhalten sicher reproduzieren kannst, (am besten auf einem neuen System oder mit einer Live-CD), dann solltest du einen Bug reporten. Vielleicht kann das noch jemand anderes testen. (Ich selber habe kein geeignetes System dafuer.)

[JTH]

Dann ist es vielleicht nur ein kleiner Bug von apt in Bullseye, hier:

Code: Alles auswählen

# apt -v
apt 2.2.4 (amd64)

Dein Listing bezieht sich ja schon auf apt 2.3.14.

Wenn sich das am Listing nicht nachvollziehen lässt -- kannst du es denn praktisch an der Kommandozeile nachvollziehen?

Das ist kein Bug, die Bash-Vervollständigungen für apt und apt-get sind einfach unterschiedlich implementiert: In /usr/share/bash-completion/completions/apt bzw. /usr/share/bash-completion/completions/apt-get.

Die Vervollständigung für apt-get ist relativ dumm und naiv und schlägt einfach die Kommandos vor (install, remove und co.) oder, wenn ein - eingegeben wurde, die langen Optionen wie --simulate, --no-install-recommends etc. Und das egal in welcher Reihenfolge. Die Vervollständigung würde dir z.B. auch das dort unsinnige changelog nach einem

Code: Alles auswählen

apt-get --no-install-recommends chTAB

vorschlagen.

Die Vervollständigung für apt versucht etwas schlauer zu sein und nach den Kommandos nur die jeweils dazu passenden Optionen vorzuschlagen. Deshalb erwartet sie erst das Kommando und schlägt dir danach die möglichen Optionen vor:

Code: Alles auswählen

apt install --simTAB

Ein anderer Unterschied: Für apt werden auch die Kurzformen wie -s vorgeschlagen:

Code: Alles auswählen

apt install -TAB

In den Vorschlägen für apt-get gibt es die Kurzformen gar nicht.

[Meillo]

@JTH: Ich weiss nicht, ob du das richtig verstanden hast. Es geht und diese zwei Zeilen:

Was ich auch nicht so ganz verstehe, wieso apt hinter -s keine TAB-Ergänzung anbietet, bei der Langform --simulate aber schon:

Code: Alles auswählen

# apt -s dist[TAB]

# apt --simulate dist[TAB]-upgrade 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Der Befehl apt-get macht hingegen die TAB-Ergänzung noch in beiden Schreibweisen. - Oder macht apt das zufällig nur in meinem Terminal so?

Beides Mal ist es `apt'.

[JTH]

@JTH: Ich weiss nicht, ob du das richtig verstanden hast. Es geht und diese zwei Zeilen:
[…]

Beides Mal ist es `apt'.

Ah ja, ich hab mich primär auf diese Beobachtung bezogen:

Der Befehl apt-get macht hingegen die TAB-Ergänzung noch in beiden Schreibweisen.

Anscheinend ist es doch ein winziger Bug:
Die Vervollständigung schaut in dieser Zeile

Code: Alles auswählen

        if [[ ${COMMANDS[@]} =~ ${words[i]} ]]; then

ob eins der bereits eingegebenen Wörter (=Parameter für das aufzurufende Programm) einem der Kommandos (install, remove, …) entspricht. Wenn man apt -s eingetippt hat, ist das einzige zu vergleichende Wort das -s. In obigem if matcht das -s dummerweise das edit-sources aus dem COMMANDS-Array. Damit wird im weiteren versucht, passende Optionen für das Kommando „-s“ vorzuschlagen – die es offensichtlich nicht gibt. Und die eigentlichen Kommandos werden schließlich hier

Code: Alles auswählen

    if [ "$command" = "" ]; then
        COMPREPLY=( $( compgen -W '${COMMANDS[@]}' -- "$cur" ) )
    fi

auch nicht mehr vorgeschlagen, weil die Variable $command nicht mehr leer ist, sondern „-s“ enthält. Das Problem könnte wegen build-dep auch die kurze Option -d betreffen.

Möchte das jemand melden? Eine Lösung wäre wohl, diese faule Variante eines ist-das-Wort-im-Array-Vergleichs durch eine Schleife über alle COMMANDS-Elemente und jeweils einzelnem Vergleich zu ersetzen.

[Meillo]

Anscheinend ist es doch ein winziger Bug:
Die Vervollständigung schaut in dieser Zeile

Code: Alles auswählen

        if [[ ${COMMANDS[@]} =~ ${words[i]} ]]; then

ob eins der bereits eingegebenen Wörter (=Parameter für das aufzurufende Programm) einem der Kommandos (install, remove, …) entspricht. Wenn man apt -s eingetippt hat, ist das einzige zu vergleichende Wort das -s. In obigem if matcht das -s dummerweise das edit-sources aus dem COMMANDS-Array.

Toller Fund! Das scheint mir plausibel zu sein.

Eine Lösung wäre wohl, diese faule Variante eines ist-das-Wort-im-Array-Vergleichs durch eine Schleife über alle COMMANDS-Elemente und jeweils einzelnem Vergleich zu ersetzen.

(Btw: Da hast du nochmal die URL von oben reinkopiert. Das wolltest du bestimmt nicht.)

Ich denke, man koennte das auch so loesen:

Code: Alles auswählen

        if [[ ${COMMANDS[@]} =~ "^${words[i]}" ]]; then

Wenn wir eh schon mit Regexps matchen, dann koennen wir auch den Wortanfang ankern ... vermute ich mal. Mit [[ und =~ kenne ich mich aber nicht aus, insofern sollte man das nur als Idee ansehen.


Das ist ein schoener Bug, bei dem man die Aenderung der in der Completion-Datei gut selber testen und dann einen Bugreport inkl. Patch absetzen. @JTH: Halte dich fest, wenn sich gleich die Massen darauf stuerzen.

[JTH]

(Btw: Da hast du nochmal die URL von oben reinkopiert. Das wolltest du bestimmt nicht.)

Doch doch, das sollte der gleiche Link sein. Einfach nochmal zum Verdeutlichen.

Ich denke, man koennte das auch so loesen:

Code: Alles auswählen

        if [[ ${COMMANDS[@]} =~ "^${words[i]}" ]]; then

Wenn wir eh schon mit Regexps matchen, dann koennen wir auch den Wortanfang ankern ... vermute ich mal. Mit [[ und =~ kenne ich mich aber nicht aus, insofern sollte man das nur als Idee ansehen.

Das geht leider nicht (wenn ich mich nicht komplett täusche). Der Operator =~ macht dort wegen des Arrays nichts spezielles – also er vergleicht nicht, weil der linke Operand ein Array ist, alle Arrayelemente mit dem rechten Operanden. Deshalb geht diese Suche ganz sauber nur über eine Schleife. Was in dem if effektiv steht ist Folgendes (einige Kommandos ausgelassen für die Lesbarkeit):

Code: Alles auswählen

        if [[ "list search show showsrc install remove […]" =~ "^${words[i]}" ]]; then

Und in dem hier beobachteten Fall eben

Code: Alles auswählen

        if [[ "[…] dist-upgrade edit-sources help […]" =~ -s ]]; then

Man könnte allerdings tricksen mit Leerzeichen um beide Operanden:

Code: Alles auswählen

        if [[ " ${COMMANDS[@]} " =~ " $1 " ]]; then

Das würde das Problem auch einfacher lösen.

Das ist ein schoener Bug, bei dem man die Aenderung der in der Completion-Datei gut selber testen und dann einen Bugreport inkl. Patch absetzen.

Mal gucken, vielleicht probier ich mich die Tage mal an meinem ersten Mini-Bugreport bei Debian. Wird Zeit nach 15 Jahren.

Halte dich fest, wenn sich gleich die Massen darauf stuerzen.

Du meinst die wilde Awok-Horde, die sich dieses Jahr noch nicht gezeigt hat?

[reox]

Es war ja auch die Frage was bei einem pointrelease passiert, jetzt hab ich endlich mal die Ausgabe gesehen:

Code: Alles auswählen

# apt update
Holen:1 http://security.debian.org/debian-security bullseye-security InRelease [44,1 kB]
Holen:2 http://deb.debian.org/debian bullseye InRelease [116 kB]
Holen:3 http://deb.debian.org/debian bullseye-updates InRelease [39,4 kB]
Holen:4 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [108 kB]
Holen:5 http://security.debian.org/debian-security bullseye-security/main Translation-en [68,6 kB]
Holen:6 http://deb.debian.org/debian bullseye/main amd64 Packages [8.183 kB]
Holen:7 http://deb.debian.org/debian bullseye/main Translation-en [6.243 kB]
Es wurden 14,8 MB in 5 s geholt (3.020 kB/s).
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 21 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
N: Für das Depot »http://deb.debian.org/debian bullseye InRelease« wurde der »Version«-Wert von »11.1« in »11.2« geändert.

Diese Meldung meinte ich und das ist auch das einzige was sich ändert, upgrade/full-upgrade wissen davon dann gar nichts.
Wenn ich mich recht erinnere, kann man auch irgendwie einstellen, dass dann eine Frage kommt ob das OK ist. Aber wie genau weiß ich jetzt adhoc auch nicht mehr...

[JTH]

Das ist ein schoener Bug, bei dem man die Aenderung der in der Completion-Datei gut selber testen und dann einen Bugreport inkl. Patch absetzen.

Mal gucken, vielleicht probier ich mich die Tage mal an meinem ersten Mini-Bugreport bei Debian. Wird Zeit nach 15 Jahren.

Meine Fehlerkorrektur ist – neben ein paar separaten anderen kleinen Verfeinerungen, wenn man schon dabei ist – im APT-Repo angekommen

[Meillo]

Klasse!

Dafuer gibt's natuerlich eine DFDE-Keks:

[JTH]

*yay* Schnell aufgegessen, bevor der Dino um die Ecke kommt. Ich seh ihn doch schon unter dem Thread in der „Wer ist online in diesem Forum“-Liste

[TRex]

(｡◕‿‿◕｡) Keks?