# [solved] Ausgabe von "qlop" als "--exclude" Liste für emerge

## schmidicom

Frage: Gibt es eine einfache Möglichkeit die Ausgabe von "qlop" als Liste für die emerge Option "--exclude" zu benutzen?

Ich möchte mein komplettes System neu bauen (Grund dafür ist der Umzug auf eine neue Hardware) und wegen dem einen oder anderen Unterbruch dabei muss ich einen Weg finden das der Befehl "emerge --oneshot -av @installed" nicht wieder komplett von vorne anfangt.Last edited by schmidicom on Fri Mar 23, 2018 2:28 pm; edited 1 time in total

----------

## Tyrus

Ich dachte dafür gibts doch "--resume".

Auszug aus der manpage zum emerge:

```

       --resume, -r

              Resumes  the most recent merge list that has been aborted due to an error.  This re-uses the arguments and options that

              were given with the original command that's being resumed, and the user may also provide additional options when  call‐

              ing  --resume.  It  is an error to provide atoms or sets as arguments to --resume, since the arguments from the resumed

              command are used instead.  Please note that this operation will only return an error on failure.  If there  is  nothing

              for  portage  to do, then portage will exit with a message and a success condition. A resume list will persist until it

              has been completed in entirety or until another aborted merge list replaces it.  The resume history is capable of stor‐

              ing  two merge lists.  After one resume list completes, it is possible to invoke --resume once again in order to resume

              an older list.  The resume lists are stored in /var/cache/edb/mtimedb, and  may  be  explicitly  discarded  by  running

              `emaint --fix cleanresume` (see emaint(1)).

```

----------

## mv

eix-installed-after -h

----------

## schmidicom

"--resume" kannte ich noch nicht und bis jetzt macht es genau das was ich mir erhofft hatte.

@mv

"eix-installed-after" habe ich mir inzwischen auch angesehen, habe es aber nicht geschafft damit eine funktionierende "--exclude" Option zusammen zu basteln.

----------

## mv

 *schmidicom wrote:*   

> damit eine funktionierende "--exclude" Option zusammen zu basteln.

 

Könnte man zwar machen (d.h. nach jedem zweiten Argument ein --exclude einfügen), aber geschickter ist es umgekehrt: Man gibt einfach alle bislang noch fehlenden Pakete an. Dazu legt man sich zu Beginn einer Update-Aktion ein "timestamp"-File an, und ab dann hat man jeweils nur noch Pakete zu bauen, die älter als dieses File sind. Das passiert dann mit so etwas wie

```
emerge -1O $(eix-installed-after -btF /pfad/zu/timestamp)
```

(oder je nach Zweck auch ohne die Option -O). Natürlich kann man den Zeitstempel des "timestamp"-Filesbei Bedarf auch gezielt mit "touch -t" setezen oder ein File aus einem Paket nehmen, das man als letztes mit "emerge" installiert hatte.

----------

## mike155

Noch drei Ergänzungen zu "--resume":

Wenn emerge abbricht, weil es ein Paket nicht installieren kann, ist manchmal auch "--resume --skipfirst" hilfreich. Dann wird das erste Paket (das den Fehler erzeugt hat) übersprungen.

emerge "--resume" arbeitet Stack-basiert: wenn ein "emerge" wegen eines Fehlers abbricht, kann man zunächst eine oder mehrere emerge-Anweisungen von Hand starten (um das fehlerhafte Paket doch noch zu installieren) - und dann mit "emerge --resume [--skipfirst]" fortfahren.  

Man kann emerge auch mit der Option "--keepgoing" (ohne "--resume") starten - dann überspringt emerge alle Pakete, bei denen es Fehler gibt. Das ist beispielsweise bei "emerge -e @world" sehr hilfreich. Hinterher kann man sich unter /var/tmp/portage die Pakete ansehen, die nicht installiert wurden - und diese nach Behebung der Fehlerursache nach-installieren. 

----------

## mv

 *mike155 wrote:*   

> Noch drei Ergänzungen zu "--resume":

 

Das Problem mit --resume ist, dass es i.W. nicht effektiver ist als --keepgoing (das man am besten ohnehin zu EMERGE_DEFAULT_OPTS hinzufügt) und daher für ein gesamtes world rebuild ungeeignet:

 *Quote:*   

> emerge "--resume" arbeitet Stack-basiert

 

Was genau wann gemacht wird ist ziemlich undurchsichtig und kann auch nicht genauer kontrolliert werden, wenn beispielsweise aus der "Restliste" etwas entfernt werden soll. Schlimmer noch ist, dass --resume (genauso wie --keepgoing) Pakete selbständig aus der Restliste entfernt, wenn die Abhängigkeiten nicht erfolgreich installiert wurden.

[qoute]Hinterher kann man sich unter /var/tmp/portage die Pakete ansehen, die nicht installiert wurden - und diese nach Behebung der Fehlerursache nach-installieren.[/quote]

Wenn man das bei einem world rebuild macht, hat man i.d.R. bei weitem nicht alle Pakete installiert, weil die Liste durch die Fehler verändert wurde.

----------

## schmidicom

@mv

Das erste Paket welches ich auf der neuen Hardware gebaut habe (zum testen ob das System zumindest so weit noch lauffähig ist) war "app-editors/nano", also müsste dessen jüngste Installation als Timestamp ja ausreichen. Und bis jetzt scheint die Liste von "eix-installed-after -b app-editors/nano" immer kürzer zu werden je weiter "emerge -resume" voranschreitet.

Mal sehen wie die Liste aussieht wenn der mit "emerge --resume" fortgesetzte rebuild aller installierten Pakete aussieht, eigentlich müssten ja nur die Pakete übrig bleiben die nicht gebaut werden konnten.

----------

## mv

 *schmidicom wrote:*   

> also müsste dessen jüngste Installation als Timestamp ja ausreichen.

 

Ja, so mache ich es auch in der Regel. Genauer: Ich bastle mir ein Timestamp-File davon mit touch --reference, falls ich das Paket aus irgendwelchen Gründen noch ein zweites mal neu bauen sollte, bevor das world rebuild ganz fertig ist. (Oft ist das bei mir erst nach Wochen der Fall, weil es praktisch immer irgendwelche Problemfälle gibt, deren Rekompilation zunächst hinausgeschoben wird)

 *Quote:*   

> eigentlich müssten ja nur die Pakete übrig bleiben die nicht gebaut werden konnten.

 

...oder die mit emerge depclean entfernt werden sollten. Soweit die Theorie. In der Praxis wird man aber wie gesagt doch das eine oder andere Problempaket wegen verschiedenster Gründe auf bestimmte oder unbestimmte Zeit verschieben: Gerade bei einem Hardwarewechsel kann man eben nicht alle Probleme gleichzeitig lösen...

----------

## mike155

 *mv wrote:*   

> Wenn man das bei einem world rebuild macht, hat man i.d.R. bei weitem nicht alle Pakete installiert, weil die Liste durch die Fehler verändert wurde...

 

Hallo mv, vielen Dank für die zusätzlichen Erläuterungen!

Mir ist noch nicht aufgefallen, dass "emerge --keepgoing @world" oder "emerge --resume [--skipfirst]" Pakete aus der Liste entfernt - aber ich halte das durchaus für möglich. Ich habe mich schon öfters gefragt, was "emerge --keepgoing" eigentlich mit abhängigen Paketen macht, wenn es ein Paket nicht installieren kann. Vermutlich genau das, was Du beschrieben hast.   

Andererseits ist es bei mir vermutlich deshalb noch nicht vorgekommen, weil ich mittlerweile vor einem "emerge -e @world" immer erst "emerge --update --deep --newuse @world" und "emerge --depclean" laufen lasse - und es dadurch bei dem "emerge -e @world" nur sehr wenige Fehler gibt.

Weiterhin prüfe ich nach einem "emerge -e @world" (wenn ich es einmal durchführe, so ca. 1-2 Mal pro Jahr) grundsätzlich die Verzeichnisse /bin, /sbin, /lib, /usr/bin, /usr/sbin, /usr/lib mit einem "ls -lart". Dadurch kann ich sehen, ob es Dateien gibt, die nicht neu installiert wurden. Dabei wären mir übersprungene Pakete aufgefallen. Weiterhin fallen natürlich Dateien und Verzeichnisse auf, die nicht in diese Verzeichnisse gehören - z.B. Dateien, die von emerge nicht richtig gelöscht wurden oder die auf andere Weise in diese Verzeichnisse gekommen sind... Ich versuche dann nachzuvollziehen, wie sie in die Verzeichnisse gekommen sind und lösche sie.

----------

