| View previous topic :: View next topic |
| Author |
Message |
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
 Posted: Wed Jan 30, 2008 8:56 pm Post subject: ccache-Nutzen |
 |
|
Gesplittet aus [gcc]gcc-4.3: -fdirectives-only -- Finswimmer
ccache habe ich ziemlich schnell wieder weggeschmissen, weil laut log so gut wie kein Code aus dem Cache genommen wurde. Hat bei mir nichts gebracht.
Viel insteressanter finde ich, dass endlich die Unterstützung für den Core2 kommt, das kitzelt bestimmt 2% mehr Performance raus. |
|
| Back to top |
|
 |
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Wed Jan 30, 2008 9:10 pm Post subject: |
|
|
Also bei mir bringt der ccache eine ganze Menge, auch laut Statistik...
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 9:14 pm Post subject: |
|
|
Bei dem einen ist Ext3 schneller, bei dem anderen reiser, bei dem einen bringt ccache was, beim anderen.... Ist das nicht irgendwie schön? Was wäre die Welt langweilig, wenn alles einfach zu erklären wäre  |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Wed Jan 30, 2008 9:20 pm Post subject: |
|
|
| hrhr. Du hast hoffentlich nicht an den CFLAGS rumgespielt. Dann kann ccache afaik nämlich nichts bringen. ^^ |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 9:24 pm Post subject: |
|
|
| Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan. |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Wed Jan 30, 2008 9:47 pm Post subject: |
|
|
| Klaus Meier wrote: | | Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan. |
Ich werd Dich nicht abhalten 
Hier mal meine Statistik:
| Code: | $ ccache -s
cache directory /var/tmp/ccache
cache hit 50185
cache miss 309007
called for link 31558
multiple source files 91
compile failed 4843
preprocessor error 3151
not a C/C++ file 13483
autoconf compile/link 43662
unsupported compiler option 8179
no input file 16306
files in cache 299094
cache size 5.5 Gbytes
max cache size 6.0 Gbytes |
|
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 9:51 pm Post subject: |
|
|
| Mr. Anderson wrote: | | Klaus Meier wrote: | | Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan. |
Ich werd Dich nicht abhalten
Hier mal meine Statistik:
| Code: | $ ccache -s
cache directory /var/tmp/ccache
cache hit 50185
cache miss 309007
called for link 31558
multiple source files 91
compile failed 4843
preprocessor error 3151
not a C/C++ file 13483
autoconf compile/link 43662
unsupported compiler option 8179
no input file 16306
files in cache 299094
cache size 5.5 Gbytes
max cache size 6.0 Gbytes |
|
Komme bei dir auf ein cache miss / cache hit Verhältnis von ca. 15%. Finde ich noch nicht so spannend. |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Wed Jan 30, 2008 10:03 pm Post subject: |
|
|
| Was erwartest Du? Ich übersetz mein System ja nicht ständig neu |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 10:13 pm Post subject: |
|
|
| Also so ab 25%, eher 30%, würde ich darin einen Vorteil sehen. Weil ccache ja auch Performance kostet. Der Cache muß angelegt werden, es muß im Cache nachgesehen werden, ob der Code schon drin ist usw. Das heißt, jedes emerge läuft langsamer, auch wenn der Code nicht im Cache gefunden wird. Bei mir lag das Verhältnis immer so bei ca. 10%. Also von den Ergebnissen her liegen wir ähnlich, wir unterscheiden uns nur darin, wie wir sie interpretieren. |
|
| Back to top |
|
|
Necoro
Veteran
Joined: 18 Dec 2005
Posts: 1912
Location: Germany
|
| Posted: Wed Jan 30, 2008 11:14 pm Post subject: |
|
|
die Menge an zusätzlich benötigtem Plattenplatz (hier 6GB) ist auch nicht zu vernachlässigen (zu mindestens nicht auf meinem Laptop  ) - genauso die damit nun notwendig werdenden Festplattenzugriffe (ich kompiliere sonst normalerweise komplett im RAM)
_________________
Inter Deum Et Diabolum Semper Musica Est. |
|
| Back to top |
|
|
69719
l33t
Joined: 20 Sep 2004
Posts: 865
|
| Posted: Thu Jan 31, 2008 8:00 am Post subject: |
|
|
| Code: |
cache directory /root/.ccache
cache hit 135161
cache miss 199525
called for link 23978
multiple source files 91
compile failed 7083
preprocessor error 7374
bad compiler arguments 2
not a C/C++ file 14687
autoconf compile/link 79843
unsupported compiler option 5044
no input file 29909
files in cache 98504
cache size 1.8 Gbytes
max cache size 2.0 Gbytes
|
wenn ich richtig liege? 67% |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Thu Jan 31, 2008 8:51 am Post subject: |
|
|
| escor wrote: | | Code: |
cache directory /root/.ccache
cache hit 135161
cache miss 199525
called for link 23978
multiple source files 91
compile failed 7083
preprocessor error 7374
bad compiler arguments 2
not a C/C++ file 14687
autoconf compile/link 79843
unsupported compiler option 5044
no input file 29909
files in cache 98504
cache size 1.8 Gbytes
max cache size 2.0 Gbytes
|
wenn ich richtig liege? 67% |
So ähnlich sah meine Statistik bis vor kurzem auch aus, was bei mir darin begründet liegt, dass ich ein testing System fahre und oft Bugfix-Releases (-r1 etc.) installiere. Dabei ändert sich in der Regel kaum was am Code, so dass man stark vom ccache profitiert. Wenn man hingegen ein stable System fährt und nur 1 x pro Monat ein Update macht, sinkt der Nutzen von ccache natürlich gewaltig.
Aber wir schweifen vom ursprünglichen Thema ab - vielleicht könnte mal ein Mod die entsprechenden Postings in einen ccache-Diskussions-Thread abspalten - danke!
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sat Feb 02, 2008 12:31 pm Post subject: |
|
|
Hab mir jetzt auch mal ccache draufgetan, weil ich dafür noch was nützliches entdeckt habe. Ich habe doch zweimal Gentoo auf der Platte, einmal Gnome, einmal KDE. Und da verlinkt das zweite /usr/portage auf das Erste, spart Platz und die Zeit fürs syncen. Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde. Hatte dann überlegt, wie man identische emerge Läufe in beiden Gentoos zusammenfassen könnte. Und ich denke, da ist ein gemeinsames ccache Verzeichnis schon einen Versuch wert.
Obwohl, ist gerade ein neues xorg rausgekommen, und nachdem der erste Durchlauf ja den Cache gefüllt hat, hat der Zweite ne ziemlich schlechte Quote. Habs vergessen zu notieren, fiel mir dann nur so am Ende auf. Wohingegen die ganzen Pakete von gstreamer, obwohl sie nur einmal durchgingen, ne Quote von ca. 1:1 erreicht haben. Da soll einer schlau draus werden. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Sat Feb 02, 2008 12:35 pm Post subject: |
|
|
| Klaus Meier wrote: | | Obwohl, ist gerade ein neues xorg rausgekommen, und nachdem der erste Durchlauf ja den Cache gefüllt hat, hat der Zweite ne ziemlich schlechte Quote. Habs vergessen zu notieren, fiel mir dann nur so am Ende auf. Wohingegen die ganzen Pakete von gstreamer, obwohl sie nur einmal durchgingen, ne Quote von ca. 1:1 erreicht haben. Da soll einer schlau draus werden. |
Verwendest Du evtl. verschiedene USE flags oder verschiedene Einstellungen für VIDEO_CARDS bzw. INPUT_DEVICES? Oder unterscheiden sich evtl. die CFLAGS zwischen den Rechnern bzw. zwischen den Compiler-Läufen?
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sat Feb 02, 2008 2:03 pm Post subject: |
|
|
[quote="schachti"] | Klaus Meier wrote: | | Verwendest Du evtl. verschiedene USE flags oder verschiedene Einstellungen für VIDEO_CARDS bzw. INPUT_DEVICES? Oder unterscheiden sich evtl. die CFLAGS zwischen den Rechnern bzw. zwischen den Compiler-Läufen? |
Ok, die Flags sind nicht identisch, ist halt eins Gnome und eins KDE. Aber ansonsten ist es identisch. Und beim xorg-server sind die Flags identisch. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Feb 02, 2008 7:00 pm Post subject: |
|
|
| Klaus Meier wrote: | | Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde. |
Schau Dir mal trickyfetch an. Ist erstens zuverlässiger als eclean-dist (weil es hundertprozentig genau die für eine Reinstallation benötigten Files beibehält) und zweitens kannst Du das problemlos für mehrere chroots (mit verschiedenen Source-Archiven) machen: Nach Installation einfach Files nach $DISTDIR/.obsolete verschieben, auf jedem der chroots ein emerge --with-bdeps -feD world ausführen (was leider etwas dauert); der Rest in $DISTDIR/.obsolete ist dann für alle chroots obsolet und kann gelöscht werden (falls Du nicht spezielle Gründe hast, das nicht zu tun). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Feb 02, 2008 7:10 pm Post subject: |
|
|
| Klaus Meier wrote: | | Und beim xorg-server sind die Flags identisch. |
Auch die CFLAGS/CXXFLAGS/LDFLAGS? Und Du bist sicher, dass Du das selbe ccache-Directory benutzt?
Dann kann es eigentlich nur an irgendwelchen Header-Files liegen: Wenn sich eines der Basis-Headerfiles unterscheidet (etwa verschiedene glibc oder gcc Versionen oder ev. auch mit verschiedenen Flags installiert) wirst Du fast nur "misses" haben...
BTW: Ich komme bei mir auf 44% Hit-Rate, und auf der 32-Bit chroot sogar auf knapp 55% (Größe jeweils 2GB). Ich benutze ccache allerdings auch beim Kernel-Kompilieren und bin außerdem anscheinend ab und an mal der erste, der auf irgendwelche Bugs in Paketen stößt: Beim Schreiben von Patches brauche ich meistens mehrere Kompilationsversuche hintereinander. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sat Feb 02, 2008 7:18 pm Post subject: |
|
|
| mv wrote: | | Klaus Meier wrote: | | Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde. |
Schau Dir mal trickyfetch an. Ist erstens zuverlässiger als eclean-dist (weil es hundertprozentig genau die für eine Reinstallation benötigten Files beibehält) und zweitens kannst Du das problemlos für mehrere chroots (mit verschiedenen Source-Archiven) machen: Nach Installation einfach Files nach $DISTDIR/.obsolete verschieben, auf jedem der chroots ein emerge --with-bdeps -feD world ausführen (was leider etwas dauert); der Rest in $DISTDIR/.obsolete ist dann für alle chroots obsolet und kann gelöscht werden (falls Du nicht spezielle Gründe hast, das nicht zu tun). |
Sehe da jetzt noch nicht den Vorteil. Ich habe jetzt einen Ordner /ust/portage ohne distfiles, den zwei Gentoos gemeinsam benutzen. Und die Distfiles speichere ich außerhalb von /usr/portage für jede Installation separat. Hätte Interesse an einer Lösung, wo ich nur noch einen Ordner Distfiles bräuchte und mit irgendeinem Befehl nur die Files gelöscht werden, die in beiden Installationen nicht mehr gebraucht werden.
Bei trickyfetch werden ja auch separate Distfiles benutzt oder hab ich das noch nicht verstanden?
Last edited by Klaus Meier on Sat Feb 02, 2008 7:24 pm; edited 1 time in total |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sat Feb 02, 2008 7:24 pm Post subject: |
|
|
| mv wrote: | | Klaus Meier wrote: | | Und beim xorg-server sind die Flags identisch. |
Auch die CFLAGS/CXXFLAGS/LDFLAGS? Und Du bist sicher, dass Du das selbe ccache-Directory benutzt?
Dann kann es eigentlich nur an irgendwelchen Header-Files liegen: Wenn sich eines der Basis-Headerfiles unterscheidet (etwa verschiedene glibc oder gcc Versionen oder ev. auch mit verschiedenen Flags installiert) wirst Du fast nur "misses" haben...
BTW: Ich komme bei mir auf 44% Hit-Rate, und auf der 32-Bit chroot sogar auf knapp 55% (Größe jeweils 2GB). Ich benutze ccache allerdings auch beim Kernel-Kompilieren und bin außerdem anscheinend ab und an mal der erste, der auf irgendwelche Bugs in Paketen stößt: Beim Schreiben von Patches brauche ich meistens mehrere Kompilationsversuche hintereinander. |
Bei mir sind beide make.conf absolut identisch (da rüberkopiert) und danach nur noch mit ufed bearbeitet. Und beide Installationen sind von der Buildumgebung her absolut identisch, da sie ja ein gemeinsames /usr/portage benutzen.
Habe es ja jetzt erst mal 24 Stunden am laufen, muß sich der Cache ja erst mal aufbauen. War halt nur komisch, dass ich Hits hatte, wo ich keine erwartet habe und keine Hits, wo ich sie erwartete. Aber kann mir doch eigentlich egal, warum mir ccache nutzt, solange es mir nutzt |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Feb 02, 2008 7:47 pm Post subject: |
|
|
| Klaus Meier wrote: | | Bei trickyfetch werden ja auch separate Distfiles benutzt |
Nein, eben nicht. Du hast ein $DISTDIR (auf das Du natürlich von beiden chroot's aus zugreifen können musst).
Dann machst Du (nachdem Du die make.conf in beiden Installationen für trickyfetch entsprechend angepasst hast) | Code: | cd $DISTDIR
mkdir .obsolete
mv * .obsolete
emerge --with-bdeps=y -feD world |
Das letzte Kommando führst du anschließend (oder auch gleichzeitig) in Deiner chroot aus.
Dadurch werden alle (in mindestens einer der beiden Installationen) benötigten Files von $DISTDIR/.obsolete wieder nach $DISTDIR geholt, und in $DISTDIR/.obsolete bleibt dasjenige, das von keinen der beiden chroots aktuell mehr benötigt wird. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sat Feb 02, 2008 7:58 pm Post subject: |
|
|
| mv wrote: | | Klaus Meier wrote: | | Bei trickyfetch werden ja auch separate Distfiles benutzt |
Nein, eben nicht. Du hast ein $DISTDIR (auf das Du natürlich von beiden chroot's aus zugreifen können musst).
Dann machst Du (nachdem Du die make.conf in beiden Installationen für trickyfetch entsprechend angepasst hast) | Code: | cd $DISTDIR
mkdir .obsolete
mv * .obsolete
emerge --with-bdeps=y -feD world |
Das letzte Kommando führst du anschließend (oder auch gleichzeitig) in Deiner chroot aus.
Dadurch werden alle (in mindestens einer der beiden Installationen) benötigten Files von $DISTDIR/.obsolete wieder nach $DISTDIR geholt, und in $DISTDIR/.obsolete bleibt dasjenige, das von keinen der beiden chroots aktuell mehr benötigt wird. |
Ok, ja, jetzt hab ich es verstanden. Mußt dann nur zum aufräumen immer wieder die jeweiligen Kommandos ausführen. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Sun Feb 03, 2008 7:27 am Post subject: |
|
|
| Klaus Meier wrote: | | Ok, ja, jetzt hab ich es verstanden. Mußt dann nur zum aufräumen immer wieder die jeweiligen Kommandos ausführen. |
Stimmt - aber das läßt sich ja per cronjob automatisieren. Und gegenüber anderen Lösungen hat trickyfetch den Vorteil, dass es tatsächlich funktioniert - bei allen anderen Lösungen, die ich bisher probiert habe, wurde die eine oder andere Abhängigkeit falsch berechnet, mal wurde zu viel gelöscht, mal zu wenig.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Sun Feb 03, 2008 7:57 am Post subject: |
|
|
Was sich bei mir jetzt so die Frage stellt, ist der Sinn von den bdeps. Warum wird das bei emerge -e auf y und bei emerge -u auf n gesetzt? Hat es einen Nachteil, wenn man es fest auf y setzt?
Hat mich ja mal bei einer Neuinstallation voll geschreddert, weil da teilweise neuere, nicht funktionierende Versionen installiert wurden als beim Update.
Und wenn man nach der Anleitung trickyfetch ausführt, dann hat man ja die Files für eine Neuinstallation auf der Platte, aber nicht unbedingt die, die zum laufenden System gehören. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Sun Feb 03, 2008 8:01 am Post subject: |
|
|
Ich habe in meiner /etc/make.conf global
| Code: |
EMERGE_DEFAULT_OPTS="--with-bdeps y"
|
gesetzt und bisher noch keine Probleme damit gehabt.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 03, 2008 1:28 pm Post subject: |
|
|
| Klaus Meier wrote: | | Was sich bei mir jetzt so die Frage stellt, ist der Sinn von den bdeps. Warum wird das bei emerge -e auf y und bei emerge -u auf n gesetzt? |
Den Default für --with-bdeps=n habe ich auch noch nie verstanden: Die meisten Leute sind nur verwirrt, wenn nicht alle Upgrades eingespielt werden, und es kann ja sogar eine Sicherheitslücke sein, wenn nicht alle installierten Pakete ge-updated werden. Ich persönlich habe ebenfalls EMERGE_DEFAULT_OPTS="--with-bdeps y" gesetzt, weil alles andere Unfug ist.
Der Wert --with-bdeps=n ist nur in Ausnahmefällen sinnvoll: Nämlich wenn man ein System hat, in dem man nur Binary-Pakete einspielt, die man auf einem anderen System vorkompiliert (etwa ein Laptop, den man grundsätzlich vom Desktop aus "versorgt", oder wenn man an einem PC-Pool die Rechner von einem "Master" aus updated). Sinnvoll wäre daher höchstens eine Kopplung des Defaults --with-bdeps=n an die Option -k o.ä.
Der Grund, weshalb ich es oben sicherheitshalber explizit mit angegeben habe, ist, dass ich davon ausgehe, dass Du die Sourcen von allen Paketen beibehalten willst; auch von denjenigen Paketen, die Du nur dazu brauchst, um andere zu installieren.
| Quote: | | Hat mich ja mal bei einer Neuinstallation voll geschreddert, weil da teilweise neuere, nicht funktionierende Versionen installiert wurden als beim Update. |
Das ist kein Bug von --with-bdeps y. Eher ist es ein Bug von --with-bdeps n, dass nicht alle Deine Pakete ge-upgradet wurden - wenn Du das viele Jahre so gemacht hättest, wären beim Update vermutlich so veraltete Tools benutzt worden, dass dieses schon alleine deswegen fehlgeschlagen wäre. Dass Du gerade das Pech hattest, dass die aktuellen (stabilen) Versionen dieser Tools Ärger machten, ist ungewöhnlich (und natürlich ein Problem das für die betreffenden Tools auf bugzilla gehört).
| Quote: | | Und wenn man nach der Anleitung trickyfetch ausführt, dann hat man ja die Files für eine Neuinstallation auf der Platte, aber nicht unbedingt die, die zum laufenden System gehören. |
trickyfetch sollte man natürlich nach dem Updaten ausführen, nicht vorher. Und nach dem Updaten sollte das installierte System mit dem übereinstimmen, was emerge --with-bdeps y -De world liefert - sonst hast Du sowieso etwas "falsch" gemacht. Sicherheitshalber kannst Du ja mit "world test" (das "world" script gibt es ebenfalls auf obiger Seite) vergleichen, ob dem tatsächlich so ist: Hin und wieder findet man da noch Pakete installiert, die von nichts mehr benötigt werden. Die sollten dann am Besten gleich von der Platte fliegen - das sind nämlich die, die auch emerge --distclean liefern würde (wobei Letzteres manche der Pakete "übersehen" hat, z.B. ältere Slots; ich weiß nicht, ob dieser Bug inzwischen behoben wurde). Natürlich muss man bei Löschen die selbe Vorsicht walten lassen, wie bie emerge --distclean, also insbesondere ggf. ein revdep-rebuild vorher aufrufen, falls ein vorher compiliertes Paket noch gegen die (aus dem ebuild schon entfernte) Abhängigkeit linkt.
Edit: Eigentlich ist es egal, ob man trickyfetch vor oder nach dem update ausführt - die Pakete, die es holt, sind die selben. Nur - insofern hast Du Recht - sollte man sich darüber im Klaren sein, dass man danach nur die Sourcen für das Update hat und nicht die für das laufende System - was ja normalerweise sinnvoll ist. Nur wenn man das Update dann nachschiebt und es macht Ärger und man will wieder "Downgraden", hat man die Sourcen u.U. natürlich zu früh gelöscht. Aber man kann die alten Sourcen ja noch bis zum Update in $DISTFILES/.obsolete stehen lassen und erst hinterher löschen.
Noch'n Edit: Natürlich kann man mit trickyfetch alternativ (oder zusätzlich) die Sourcen vom laufenden System behalten: Man muss dann halt ein | Code: | | world installed | sed s/^/=/ | xargs emerge -f --nodeps |
statt des (bzw. zusätzlich zum) | Code: | | emerge --with-bdeps y -feD world |
ausführen.
Last edited by mv on Sun Feb 03, 2008 1:40 pm; edited 1 time in total |
|
| Back to top |
|
|
|
Deutsches Forum (German) 
