Portage update - highly recommended to

[Erdie]

Ab und zu liefert Portage ja die Meldung, dass eine Portage Update zur Verfügung steht und es "highly recommendet" sei dieses zuerst zu mergen.

Ich frage mich jedesmal, wenn das dann so wichtig ist, Portage nach vorne zu stellen, warum Portage das dann nicht automatisch selbst macht. Wenn ich
Portage Entwickler wäre, würde ich das als erstes tun statt eine Meldung herauszugeben. Es ist immer eine bessere Möglichkeit etwas zu automatisieren, wenn das einfach möglich ist. Und ich sehe an dieser Stelle kein technisches Problem. Ich arbeite seit Jahren im Cloud Umfeld, GCP, AWS, Azure und Ali, und wir automatisieren alles, was nicht bei 3 auf den Bäumen ist.
Gibt es vielleicht einen Grund, warum das hier nicht gemacht wird?

[schmidicom]

Ist jetzt nur eine Vermutung aber vielleicht kann Portage nach dem Update von sich selbst nicht "sauber" neustarten um dann die restlichen Updates abzuarbeiten.

[Erdie]

Ist jetzt nur eine Vermutung aber vielleicht kann Portage nach dem Update von sich selbst nicht "sauber" neustarten um dann die restlichen Updates abzuarbeiten.

Ja, das wäre möglich, stimmt.

[Max Steel]

Ist jetzt nur eine Vermutung aber vielleicht kann Portage nach dem Update von sich selbst nicht "sauber" neustarten um dann die restlichen Updates abzuarbeiten.

Ich bilde mir ein dass ich portage schon habe neustarten sehen nach einem update. Aber es ist möglich dass es wirklich nicht "sauber" funktioniert.

Ich frage mich jedesmal, wenn das dann so wichtig ist, Portage nach vorne zu stellen, warum Portage das dann nicht automatisch selbst macht.

Ich vermute dass es dabei zu Problemen bei der Dependency Auflösung geben könnte wenn man einzelnen Paketen (und dessen Abhängigkeiten) Vorzüge dabei gibt was dann wieder zu Schmerzen führen könnte die sich keiner aufladen möchte. Immerhin... Dependency Auflösung ist schon Schmerzhaft genug mit Slots, Subslots, Circular-Deps, Konfigurierbare Dependencies (mit USE oder Architektur) und zusätzlich noch Maskings, und so weiter...

Es kann sein dass man sich darüber schon Gedanken machte, aber die Schmerzen den möglichen Vorteilen einfach nicht gerecht wurde.

[ChrisJumper]

Hi Erdie,

hier noch ein anderer Gedanke, wofür dieser Hinweis sein könnte: Zum Beispiel wenn mehrere Portage-Instanzen (nach dem Update in unterschiedlicher Version) laufen. Klingt seltsam, aber bei einer Maschine wo jeman per ssh eingeloggt ist oder jemand auf mehreren ttys oder Terminals arbeitet könnte es schon mal vor kommen.

Natürlich gibt es mehr Nach- als Vorteile, mehrere Portage Instanzen paralell zu verwenden, bei einem World Update, nehme ich mir trotzdem die Freiheit mal anderes Paket neu hinzu zu fügen oder es zu entfernen. Wichtig ist natürlich das aufgrund der Abhängigkeiten klar erkenntlich ist ob es zu Problemen führen kann oder nicht.

Deswegen bin ich mir noch nicht so ganz sicher ob ich es mag, wenn Portage auto-Updates macht. Das es für Neueinsteiger:innen sinvoll ist, da habe ich keinen Zweifel.

In Zeiten des Klimawandels ist es gut, wenn bestimmte Compilerprozesse sich verkürzen könnten, ohne an Transparenz zu verlieren. Ich würde mir wünschen, wir könnten eine Gentoo-Web-of-Trust Community bauen, wo dann Pakete mit der selben Konstellation, nicht nur zusammen compiliert werden sondern bei gleichen Useflags auch geteilt. Was wahrscheinlich aber zu komplex ist. Auch geht dabei zu viel des selber kompilierens verloren oder dem schnellen hinzufügen eines E-Builds.

Dennoch bin ich sehr froh darüber wie sich Gentoo aktuell weiterentwickelt und das die Community überhaupt noch existiert.

Grüße