apt 2.9.29 changelog

[bensmac]

Hallo,

im changelog von apt 2.9.29 (unstable) sind folgende Zeilen, für welche ich eine Erklärung bräuchte.

- dist-upgrade now installs Essential packages

Die Essentials sollten doch schon bei der Installation dabei sein, oder?

- Recommends for upgrades of installed dependencies are now upgraded
to Depends if they are new or previously satisfied; to avoid breaking
Recommends or introducing unsatisfied Recommends in an upgrade.

Beeinflusst dieses diese Einstellung?

Code: Alles auswählen

APT::Install-Recommends "0"

Und als letztes: Gibt es einen Hintergrund, warum

Code: Alles auswählen

modernize-sources

nur mit dem Befehl apt, jedoch nicht mit apt-get funktioniert? (Technisch, kein Glaubenskrieg )

Danke
bensmac

[michaa7]

...
Und als letztes: Gibt es einen Hintergrund, warum

Code: Alles auswählen

modernize-sources

nur mit dem Befehl apt, jedoch nicht mit apt-get funktioniert? (Technisch, kein Glaubenskrieg )
...

apt ist ein Aufsatz auf apt-get und Konsorten. Es richtet sich nach allem was man in verschiedenen man-pages dazu lesen kann direkt an den Endanwender, für den es bestimmte Optionen entsprechend setzt. Es ist auf interaktiven Gebrauch optimiert, apt-get rückt daher für den Endanwender immer mehr in den HG und spielt im wesentlichen für den weiteren Gebrauch in Scripten eine Rolle.

Der interaktive Anwendungsfall "modernize-sources" hat dementsprechend wohl dazu geführt es mit apt zu veröffentlichen und nicht in apt-get zu integrieren, weil dieses Komando wohl nie blind mit einem script ausgeführt werden sollte.

[bensmac]

Hallo michaa7,

danke für den Hinweis "interaktiv" und "end user".
Dann ergibt apt gegenüber apt-get auch Sinn.
Und wenn ich man apt >ordentlich< gelesen hätte ,
wäre es mir dieses unter dem Stichpunkt Description auch aufgefallen.

So, mal sehen, ob noch jemand Infos zu essentials und recommends in der neuen apt-Version hat.

bensmac

[Meillo]

- Recommends for upgrades of installed dependencies are now upgraded
to Depends if they are new or previously satisfied; to avoid breaking
Recommends or introducing unsatisfied Recommends in an upgrade.

Beeinflusst dieses diese Einstellung?

Code: Alles auswählen

APT::Install-Recommends "0"

Fuer mich liest sich das so, dass im Falle von Upgrades in bestimmten Faellen diese Einstellung ueberschrieben wird weil APT manche Recommends so behandelt als waeren es Depends.

In welchen konkreten Faellen das welche konkreten Probleme verhindert wuerde mich interessieren. Weiss jemand naeheres dazu?

Ich kann mir bislang nur die Konstellation vorstellen, dass Paket A ein Recommend auf B hatte oder neu bekommt, Paket B aber vormals als Dependency von Paket C installiert worden ist. Dann wird beim Upgrade Paket C durch D ersetzt, das keine Dependency mehr fuer B hat, wodurch B entfernt werden koennte. Das koennte man verhindern wollen indem A das Paket B nicht nur recommendet sondern dependet. Dann ist es nach dem Upgrade auf jeden Fall weiterhin vorhanden.

Das macht fuer mich aber nur Sinn wenn B schon auf dem System war. Wenn A in der neuen Version nur ein neues Recommend fuer ein bisher noch nicht installiertes Paket E enthaelt, dann sollte das nicht neu installiert werden, IMO. Aber es kann natuerlich sein, dass der Changelog-Eintrag diesbezueglich vollkommen exakt ist.

[Meillo]

- dist-upgrade now installs Essential packages

Die Essentials sollten doch schon bei der Installation dabei sein, oder?

Ich koennte mir vorstellen, dass alle neu dazu gekommenen Essential-Pakete automatisch installiert werden.

[MSfree]

Fuer mich liest sich das so, dass im Falle von Upgrades in bestimmten Faellen diese Einstellung ueberschrieben wird weil APT manche Recommends so behandelt als waeren es Depends.

Ich verstehe das so:

apt installiert bei Neuinstallation von Software die recommends grundsätzlich mit. Wenn bei einem dist/full-upgrade einige vorhandene Pakete neue recommends mitbringen, dann werden die ebenfalls mitinstalliert.

Der Mechanismus, recommends abzuklemmen, wenn man

Code: Alles auswählen

APT::Install-Recommends "0"

eingestellt hat, bleibt vorhanden. Dann werden nie recommends eingespielt, auch dann nicht, wenn Pakete neue recommends mitbringen.

[Meillo]

Fuer mich liest sich das so, dass im Falle von Upgrades in bestimmten Faellen diese Einstellung ueberschrieben wird weil APT manche Recommends so behandelt als waeren es Depends.

Ich verstehe das so:

apt installiert bei Neuinstallation von Software die recommends grundsätzlich mit. Wenn bei einem dist/full-upgrade einige vorhandene Pakete neue recommends mitbringen, dann werden die ebenfalls mitinstalliert.

Der Mechanismus, recommends abzuklemmen, wenn man

Code: Alles auswählen

APT::Install-Recommends "0"

eingestellt hat, bleibt vorhanden. Dann werden nie recommends eingespielt, auch dann nicht, wenn Pakete neue recommends mitbringen.

Ja, dass diese Zeile dies normalerweise bewirkt stimmt. Es gibt jedoch um etwas anderes, soweit ich das verstehe: `` Recommends for upgrades of installed dependencies are now upgraded to Depends if ...'' -- aus Recommends werden Depends, so lese ich das. Damit wird ihre Installation erzwungen. Folglich kann die Konfigurationszeile fuer diese Pakete keine Auswirkung mehr haben.

Allerdings sind dies nur meine Betachtungen auf Basis der buchstueckhafen Informationen hier im Thead. Gesucht sind eigentlich die Hintergruende dieser Aenderung.

[hikaru]

Ich kann mir bislang nur die Konstellation vorstellen, dass Paket A ein Recommend auf B hatte oder neu bekommt, Paket B aber vormals als Dependency von Paket C installiert worden ist. Dann wird beim Upgrade Paket C durch D ersetzt, das keine Dependency mehr fuer B hat, wodurch B entfernt werden koennte.

Falls du dich hier auf autoremove beziehst, das entfernt nur Pakete, die keinen Installationsgrund mehr haben. Sowohl Depends, als auch Recommends und Suggests gelten als Installationsgrund. Das ist unabhängig von der Einstellung ob apt Recommends oder Suggests mitinstallieren soll.
Wenn also C durch D ersetzt wird, dann bleibt B auch nach einem autoremove erhalten, so lange A noch installiert ist und mindestens ein Suggests auf B hat.

Das Einzige was sich in deinem Szenario durch den Austausch von C gegen D ändert ist, dass man danach B manuell deinstallieren könnte, ohne C/D zu entfernen bzw. kaputtzumachen.
So ist jedenfalls das bisherige Verhalten von apt. Möglicherweise hat sich das nun geändert und der Changelog-Eintrag sagt genau das aus. Ich kann mir allerdings nicht vorstellen, dass man solch eine Entscheidung bei Debian getroffen hat (schon gar nicht ohne viel Wind), denn das wäre konzeptuell extrem hässlich. Nicht nur könnte man sich nicht mehr auf die Bedeutung von Depends, Recommends und Suggests verlassen, auch Releases wären nicht mehr atomar, sondern ihr Verhalten würde außerdem von ihrer Geschichte abhängen.

Letzteres wäre zugegebenermaßen nicht ganz neu:
viewtopic.php?f=27&t=156295

[Meillo]

Das Einzige was sich in deinem Szenario durch den Austausch von C gegen D ändert ist, dass man danach B manuell deinstallieren könnte, ohne C/D zu entfernen bzw. kaputtzumachen.

Manuell deinstallieren kann man automatisch installierte Recommends doch jederzeit ohne das Hauptpaket dadurch mitzuentfernen. Oder nicht?

Du bringst mich auf den Gedanken, dass man sie (wenn noetig) auch automatisch deinstallieren koennte, um Konflikte aufzuloesen. (Natuerlich nur wenn es auch automatisch installiert worden ist.) Irgendwie muss man ja einen Upgrade-Pfad finden ... Und das wuerde weitere Optionen in schwierigen Abhaengigkeitssituationen bieten. Die vielleicht in die apt-Programme eingebaut worden sind und nun verhindert werden sollen ...?


Um es genau raufzufinden muesste wohl mal jemand durch das Quellcode-Repo von APT, durch den Bugtracker oder durch die Mailinglisten suchen ... Irgendwo muss sich ja mehr darueber finden ... (``Jemand sollte ...'' )

[hikaru]

Manuell deinstallieren kann man automatisch installierte Recommends doch jederzeit ohne das Hauptpaket dadurch mitzuentfernen. Oder nicht?

Ja, natürlich. Aber in deinem Beispiel ist B ein Depends von C. B zu entfernen würde also entweder auch C entfernen, oder es beschädigen. Tauscht man nun C gegen D aus, welches kein Depends auf B hat, so bliebe B auch nach einem autoremove erhalten, weil es nach wie vor ein Recommends von A ist. Man könnte B aber problemlos manuell entfernen, weil es als bloßes Recommends bei seiner Entfernung A nicht beschädigt.

Du bringst mich auf den Gedanken, dass man sie (wenn noetig) auch automatisch deinstallieren koennte, um Konflikte aufzuloesen. (Natuerlich nur wenn es auch automatisch installiert worden ist.)

Ich meine, das passiert bereits. Ich war allerdings zu selten in der Situation um das mit Sicherheit sagen zu können.

(``Jemand sollte ...'' )

[Meillo]

(``Jemand sollte ...'' )

Also gut, dann recherchiere ich halt mal ...

Hier ist der Commit der Aenderung:
https://salsa.debian.org/apt-team/apt/- ... feec263e1e

Es geht also, wie vermutet, um das Aufloesen von Konfliken und dem Finden eines Upgrade-Pfads.

Die Code-Aenderung verstehe ich zwar nicht, aber die Commit-Message ist nochmal eine andere Beschreibung der gleichen Sache, was vielleicht mehr Erleuchtung bringt:

Already satisfied Recommends should be promoted to Depends; as well
as Recommends that are new, if the version they are from is an upgrade
(such that upgrading does not introduce unsat Recommends).

This only works for the case where the new Recommends actually
exist; test-resolve-by-keep-new-recommends is not yet implemented,
but this means the phasing tests will behave correctly.

Hier zudem der Commit bzgl. der Essential-Aenderung:
https://salsa.debian.org/apt-team/apt/- ... c9d11e35f9

Irgendwie scheint die damit zu tun zu haben, dass ein dist-upgrade keine eigene Operation ist, sondern nur ein Set von einfacheren Operationen und dass dabei die Essential-Pakete nicht beruecksichtigt werden, was man bei einem dist-upgrade aber haben will. So reime ich mir das zusammen.


Beides scheinen Aenderungen zu sein, die sich in der Entwicklung ergeben haben und keine Bugfixe. Zwar habe ich Bugreports gefunden, die in entfernter Weise damit in Bezug stehen koennten, aber keine, die direkt dazu passen.

[bensmac]

Danke für die Denkanstöße und das Herausuchen.
Lassen wir uns überraschen, wie es in Zukunft funktioniert.

bensmac

[whisper]

Weils gerade zum Thema passt.
Wer wie ich Multiarch nutzt, also i386,AMD64.
Der wird, -- wenn er Fremdquellen wir chrome oder signal eingebunden hat --
Über Warnungen wie

Hinweis: Das Laden der konfigurierten Datei »main/binary-i386/Packages« wird übersprungen, da das Depot »https://updates.signal.org/desktop/apt xenial InRelease« die Architektur »i386« nicht unterstützt.

stolpern.
Das kann man abschalten mit Architectures: amd64
Näheres hier in meinem Wiki :https://daucity.de/de/apt