Alternative zu emerge -e world.

Message

Klaus Meier · Post by **Klaus Meier** » Fri Oct 23, 2015 8:48 am

Es gibt ja durchaus Situationen, in denen emerge -e world das Problem löst, aber es ist irgendwie als ob man mit Kanonen auf Spatzen schießt. Für was braucht man emerge -e world? Für eine Neuinstallation, beim Wechsel auf gcc5 und aktuell leider auch für KDE. Irgend etwas stürzt bei KDE nach einem Update fast immer ab, was sich dann mit einem emerge -e world beheben lies. Die Variante mit qlist, welche Josef95 hier ja mal erwähnt hat, die hat bei mir oft Dinge getan, die so nicht sein sollten.

Erster Fall: Neuinstallation. Es sollten nach einer Neuinstallation alle Pakete noch mal gebaut werden, welche noch nicht mit dem aktuellen gcc und den aktuellen Flags gebaut wurden und die auch mit dem gcc erzeugt wurden. Nur wie findet man heraus, welche das sind? Oft wurde da emerge -e world gemacht, weil man sonst keine Idee hatte. Ganz einfache Lösung:

Code: Select all

find /var/db/pkg/ -type d -printf '%T+ %p\n' | sort -r

In /var/db/pkg stehen ja alle Pakete drin, diese einfach nach Datum/Zeit sortieren und alles nötige neu bauen, welches älter ist als der gcc. Kann man eigentlich per Hand machen.

Wenn dann tatsächlich mal ein emerge -e world nötig ist, dann stört mich daran, dass sinnlos alles gebaut wird, in einer absolut schlechten Reihenfolge und man es schlecht in Schritten durchführen kann, weil sich portage für ein emerge --resume nicht ändern sollte. Also habe ich ein Script geschrieben, welches im Prinzip das oben beschriebene automatisiert.

Code: Select all

#! /bin/bash
declare a=0
find /var/db/pkg/ -mindepth 2 -type d -printf '%T+ %p\n' | sort | cut -d/ -f4- | sed 's:pkg/:=:' > /tmp/world
nano /tmp/world
while read ebuild
        do
                let a++
                echo ebuild Nr. $a $ebuild
                emerge -1 $ebuild
        done < /tmp/world

Vorteil gegenüber emerge -e world: Es werden die ältesten Anwendungen zuerst gebaut und nicht die, welche man vielleicht gerade erst gestern installiert hat. Man kann den Vorgang unterbrechen und jederzeit fortsetzen. Anwendungen, die man erst mal nicht neu bauen will, kann man aus der Liste entfernen. Pakete, die gar nicht neu gebaut werden sollen, befördert man mit touch /var/db/pkg/Paket ans Ende der Liste. Wenn man nur einen Teil neu bauen will, dann kann man ja noch ein grep einfügen.

Mit diesem Script schaffe ich es, mein KDE am Leben zu erhalten. Da ich ja nicht der Einzige bin, der von diesem Problem betroffen ist, kann es anderen vielleicht etwas helfen. Ich bin in diesem Bereich jetzt nicht so der Experte, wenn da jemand Verbesserungsvorschläge hat. Des weiteren ist keine Abfrage zum Beenden eingebaut. Z.B. könnte man für eine Neuinstallation abfragen, ob $ebuild der aktuelle gcc ist und dann das Script beenden.

Des weiteren habe ich noch nichts gefunden, wie man dieses Skript beenden kann außer mit kill. Mit Ctrl+C killt man nur emerge, das Skript läuft weiter. Könnte man eventuell über den Rückgabewert von emerge lösen. Aber da hatte ich noch keine Zeit zu, mich drum zu kümmern.

Yamakuzure · Post by **Yamakuzure** » Fri Oct 23, 2015 9:36 am

Nach einem Upgrade von gcc reicht eigentlich:

Code: Select all

eix-installed-after -b sys-devel/gcc

Die Reihenfolge der Abhängigkeiten sollte man schon von portage regelen lassen. Es ist nicht sonderlich sinnvoll ein Programm vor den Bibliotheken, von denen es abhängt, neu zu bauen.

Klaus Meier · Post by **Klaus Meier** » Sun Oct 25, 2015 8:19 am

eix-installed-after kannte ich bislang noch nicht. Aber auch das erfüllt nicht meine Wünsche. Es handelt sich ja bei mir ausschließlich um rebuilds. Es werden keine neuen Pakete installiert oder upgedatet. Von daher ist die Reihenfolge erst mal egal. Ich möchte aber bewusst mit der ältesten Datei anfangen. Deshalb rufe ich ja auch emerge mit jedem Paket einzeln auf. Ansonsten könnte ich ja auch gleich die ganze Liste am Stück übergeben.

Yamakuzure · Post by **Yamakuzure** » Mon Oct 26, 2015 7:55 am

eix-installed-after hat nach dem Upgrade von gcc-4.9 auf gcc-5.2 bei mir vollkommen ausgereicht.

Wenn du eine explizite zeitliche Abfolge möchtest, ist das Skript für dich natürlich unzureichend.

Auf der anderen Seite hast du keinerlei echten Vorteil von deinem Aufwand. Die zeitliche Abfolge, mit der die aktuellen Pakete auf deinem System installiert wurden, hängt ja nur von den zeitlichen Abfolgen der Updates ab. Ich sehe den Sinn nicht, dies nachzubauen.
Wenn X von Y abhängt, ist es doch egal, ob Y nach X einmal aktualisiert wurde. Deshalb nun Y vor X zu bauen ergibt keinen Vorteil.
...außer natürlich ich übersehe gerade den entscheidenden Faktor...

Klaus Meier · Post by **Klaus Meier** » Thu Nov 05, 2015 3:48 pm

Habe das ganze jetzt benutzbar gemacht. Wichtig ist für mich, dass ein rebuild der ältesten Anwendung stattfindet und auch genau diese Version und keine andere und da auch nichts umsortiert wird. Ich mache das jetzt so, dass ich jeden Tag, zusätzlich zu den Updates einen Rebuild der 10 ältesten Pakete durchführe und seitdem bin ich ein paar Probleme los, z.B. bei Multimediaanwendungen. Dazu in einem anderen Artikel mehr.

Die aktuelle Version sieht so aus:

Code: Select all

#! /bin/bash
declare a=0
find /var/db/pkg/ -mindepth 2 -type d -printf '%T+ %p\n' | sort | cut -d/ -f4- | sed 's:pkg/:=:' > /tmp/world
nano /tmp/world
while read ebuild
        do
                if [ $a = 10 ]
#              if [ $ebuild = "=sys-devel/gcc-5.2.0" ]
                then
                        exit
                fi
                let a++
                echo ebuild Nr. $a $ebuild
                emerge -1 $ebuild
                if [ $? = 130 ]
                then
                        exit
                fi
        done < /tmp/world

So wie es da steht, gibt es einen Rebuild von 10 Paketen. Man kann es aber auch alle Pakete übersetzen, die z.B. älter sind als der gcc. Und man kann es mit CTRL+C abbrechen.

bell · Post by **bell** » Mon Mar 28, 2016 9:10 pm

Interessanter Ansatz, die 10 ältesten neu zu bauen. Bisher habe ich 1-2x pro Jahr alles neu gebaut, hauptsächlich weil teilweise Ebuilds geändert wurden ohne einen Versionssprung: http://www.gentooforum.de/artikel/15321 ... erung.html
Das Skript dazu: http://www.gentooforum.de/artikel/15431 ... nkies.html unter Punkt 4.
Muss zugeben dass ich aus Faulheit es selbst nicht mehr nutze, da lasse ich das "-e world" über Nacht laufen wenn es irgend wo klemmt.

py-ro · Post by **py-ro** » Tue Mar 29, 2016 11:59 am

Klaus Meier wrote:Es werden keine neuen Pakete installiert oder upgedatet. Von daher ist die Reihenfolge erst mal egal.

Genau da ist ein kritischer Denkfehler, du baust ein Paket neu, gegen eine Lib die noch nicht neugebaut wurde und baust ggf. danach die Lib neu, wäre z.B. beim Umstieg von gcc 4 auf 5 zum Teil halt fatal. Kannst natürlich Glück haben, das zufällig die richtige Reihenfolge entsteht.

Klaus Meier · Post by **Klaus Meier** » Tue Mar 29, 2016 2:19 pm

py-ro wrote:
Klaus Meier wrote:Es werden keine neuen Pakete installiert oder upgedatet. Von daher ist die Reihenfolge erst mal egal.
Genau da ist ein kritischer Denkfehler, du baust ein Paket neu, gegen eine Lib die noch nicht neugebaut wurde und baust ggf. danach die Lib neu, wäre z.B. beim Umstieg von gcc 4 auf 5 zum Teil halt fatal. Kannst natürlich Glück haben, das zufällig die richtige Reihenfolge entsteht.

Ich habe ja auch nirgendwo gesagt, dass es die optimale Lösung für gcc4 -> gcc5 ist. Aber emerge -e world war für dieses Problem eine noch schlechter Lösung. Es gab dazu ja auch eine News.

Mir ging es zum einen darum, wie bell es ja auch sagte, dass manchmal ebuilds aktualisiert werden, ohne dass sich an der Versions-Nr. etwas ändert. Oder wie es mir beim gcc aufgefallen ist, dass es da schon neue Dateien gibt, sich aber an der Version nichts ändert. Keine Ahnung, was da passiert. Genauso läuft der vlc jetzt halbwegs stabil und einige Problem mit KDE habe ich auch so in den Griff bekommen.

Mir ging es nur darum, dass bei emerge -e world durchaus Pakete neu gebaut werden, die man erst in den letzten Stunden aktualisiert hat und die, die schon Monate alt sind, kommen dann irgend wann am Schluss. Das finde ich unlogisch. Und es gibt Pakete, die brauchen gar keinen manuellen Rebuild, weil sie sowieso alle paar Tage/Wochen aktualisiert werden. Warum soll ich mich um die manuell kümmern?

py-ro · Post by **py-ro** » Tue Mar 29, 2016 2:38 pm

Normalerweise musst du ja auch nie ein "-e world" machen, außer wenn du unbedingt für einen neuen Prozessor umbauen musst. Das ist eigentlich immer die "falsche" Lösung.

Klaus Meier · Post by **Klaus Meier** » Tue Mar 29, 2016 3:49 pm

Stimmt, theoretisch bräuchtest du es nicht. Aber die Praxis hat mir anderes gezeigt.

ich gebe zu, ich habe das vorhin etwas deppert formuliert. Meine Intention war, warum soll ich ein Paket gegen eins neu bauen, welches älter ist? Das bringt doch nichts. Es macht doch nur Sinn, ein Paket gegen eins neu zu bauen, welches neues ist.

Josef.95 · Post by **Josef.95** » Wed Jun 29, 2016 2:28 pm

bell wrote:[...]Bisher habe ich 1-2x pro Jahr alles neu gebaut, hauptsächlich weil teilweise Ebuilds geändert wurden ohne einen Versionssprung:[...]

Dafür gibt es inzwischen auch eine emerge--option --changed-deps

Post by **toralf** » Thu Jun 30, 2016 1:50 pm

Bzgl. major upgrade vom GCC von 4 auf 5:

Code: Select all

revdep-rebuild --library libstdc++.so.6 -- --exclude gcc