# emerge --depclean

## SarahS93

Was genau macht ein "emerge --depclean" eigentlich?

Sollte das wirklich immer nach einem "emerge -uaDvN world" durchlaufen gelassen werden?

Welche anderen Dinge, wenn nicht angegeben, sollten nach einem "emerge -uaDvN world" noch durchlaufen gelassen werden?

----------

## franzf

```
man emerge
```

und schauen was unter "--depclean" steht.  :Wink: 

Zusammengefasst: Es entfernt Pakete, die nicht im worldfile stehen, also als Abhängigkeit (dependency) eines anderen Pakets installiert wurden, aber durch ein update nicht mehr benötigt werden.

----------

## oliver2104

Nach einem erfolgreichen world-update ist ein "emerge --depclean" sicher angebracht.

Ich bevorzuge aber "emerge --depclean --exclude gentoo-sources" , das verhindert die

Löschung der aktuellen Kernelkonfiguration unter "/usr/src/linux/.config" die möglicherweise

zuvor mühsam erarbeitet wurde.

Je nachdem was upgedatet wurde kann auch

```

  >python-updater

  >perl-cleaner all 
```

ratsam sein

----------

## franzf

 *oliver2104 wrote:*   

> Löschung der aktuellen Kernelkonfiguration unter "/usr/src/linux/.config" die möglicherweise
> 
> zuvor mühsam erarbeitet wurde.

 

Nö  :Wink: 

Die .config ist nicht Teil des sources-Pakets, die wird erst mit einem make config erstellt, oder halt reinkopiert. Selbst die ganzen objectfiles und  module und der kernel selber (bzImage) bleiben erhalten. Sollte also ganz ungefährlich sein. emerge --depclean (ebenso --unmerge) belässt nämlich neue Dateien IMMER und natürlich auch nicht-leere Verzeichnisse werden nicht entfernt.

----------

## mv

 *SarahS93 wrote:*   

> Welche anderen Dinge, wenn nicht angegeben, sollten nach einem "emerge -uaDvN world" noch durchlaufen gelassen werden?

 

Ich habe ein emerge.finalize script, das u.a. folgendes ausführt:

 Rücksetzen einiger SUID-Programme auf meine Wünsche  emaint -f cleanconfmem  emaint -f cleanresume  eclean -d packages  emainf -f binhost  logclean all (mit logclean aus dem mv overlay) Ach ja: Ähnlich wie python-updater und perl-cleaner rufe ich ja nach Bederf zuweilen auch auf  revdep-rebuild (ich benutze kein preserved-rebuild von portage, weil das zuweilen nicht das Gewünschte macht)  find_cruft / (mit find_cruft aus dem mv overlay) und anschließendes Aufräumen  Aufräumen der Disfiles mit "obsolete" aus trickyfetch vom mv overlay  Die letzten vor allem deswegen nicht allzu regelmäßig, weil sie jeweils lange brauchen...

Und regelmäßig vor und nach emerge rufe ich eix-test-obsolete auf und räume dementsprechend meine /etc/portage/package.* directories auf.

----------

## tazinblack

 *franzf wrote:*   

>  *oliver2104 wrote:*   Löschung der aktuellen Kernelkonfiguration unter "/usr/src/linux/.config" die möglicherweise
> 
> zuvor mühsam erarbeitet wurde. 
> 
> Nö 
> ...

 

Das finde ich bei der Verwendung von genkernel sehr schön, dass er nach erfolgreichem Kernelkompile die .config mit Versionskennzeichnung im Namen nach /etc/kernels kopiert. So kann man auch noch mal nachvollziehen, was man bei älteren Kerneln verwendet hat. Dort benenne ich dann auch mal was um, wenn ich was ändere und nicht weiß ob es klappt. Baut man den Kernel in der gleichen Version neu, holt genkernel die Konfig wieder von dort.

```

ls -l /etc/kernels/

insgesamt 828

-rw-r--r-- 1 root root 100582  9. Jan 2014  kernel-config-x86_64-3.10.17-gentoo

-rw-r--r-- 1 root root 100310 24. Jan 2014  kernel-config-x86_64-3.10.25-gentoo

-rw-r--r-- 1 root root 100310  7. Mär 2014  kernel-config-x86_64-3.10.32-gentoo

-rw-r--r-- 1 root root 102688 30. Apr 2014  kernel-config-x86_64-3.12.13-gentoo

-rw-r--r-- 1 root root 102688 29. Mai 2014  kernel-config-x86_64-3.12.20-gentoo

-rw-r--r-- 1 root root 106980 28. Aug 15:26 kernel-config-x86_64-3.14.14-gentoo

-rw-r--r-- 1 root root 105069 23. Aug 11:24 kernel-config-x86_64-3.14.14-gentoo_ohne_rndis

-rw-r--r-- 1 root root 108581 24. Okt 13:52 kernel-config-x86_64-3.16.5-gentoo

```

----------

## Helmering

 *SarahS93 wrote:*   

> Welche anderen Dinge, wenn nicht angegeben, sollten nach einem "emerge -uaDvN world" noch durchlaufen gelassen werden?

 

Das ist mein Standard:

1. Meines Erachtens nach das Wichtigste: Lesen der "emerge" Logs. Da sind häufig Hinweise auf Konfigurationsprobleme ecc enthalten. Hierzu benutzte ich den im Portage verfügbaren "elogviewer". Um hier nur die wichtigen Dinge anzuzeigen habe ich in meiner /etc/portage/make.conf folgende Zeilen:PORTAGE_ELOG_CLASSES="warn error log"

PORTAGE_ELOG_SYSTEM="save"

PORT_LOGDIR="/var/log/portage" Nach dem Lesen das Verzeichnis /var/log/portage am besten löschen.

2. 

```
# emerge --depclean -a
```

 um nicht weiter notwendige Pakete zu entfernen.

3. 

```
# revdep-rebuild -i
```

 um eventuelle Abhängigkeitsprobleme zu lösen. emerge macht das mittlerweile recht brauchbar von sich aus, aber (noch) nicht in allen Fällen. Ebenso wie mv benutzte ich kein "preserved-rebuild". Dazu in der make.conf die Zeile: FEATURES="-preserve-libs"

4. 

```
# eclean -d distfiles
```

 um nicht weiter benötigte Quelldateien zu entsorgen.

"python-updater" und "perl-cleaner all" sind bei grossen Python und Perl Updates notwendig. Meist wirst Du aber in einem "News" Eintrag nach einem Portage-sync darauf hingewiesen. Anschliessend: 

```
# eselect news read
```

.

Ergo: Immer schön lesen ;=)

P.S.: Das "world-file" (/var/lib/portage/world) im Auge behalten. Durch eine vergessene "1" bei den emerge Optionen sammelt sich hier gerne alles Mögliche an was einem später das Gentoo Leben schwer machen kann.

Gruss Ralf

----------

## kurisu

 *Helmering wrote:*   

> Das ist mein Standard:
> 
> [...]
> 
> Gruss Ralf
> ...

 

+1

Abgesehen von der zusätzlichen Verwendung des dankenswerterweise seitens mv zur Verfügung gestellten find_cruft halte ich das genauso. Für all diejenigen, die kein Qt wollen, dürfte zudem das Curses-basierte app-portage/elogv anstelle von app-portage/elogviewer interessant sein.

Im Übrigen frohe Weihnachten.

----------

