# emerge --update --deep

## forrestfunk81

Bin vorhin über eine Funktion in Eix gestolpert:

 *eix --help wrote:*   

> -u, --update          Match packages without best slotted version.

 

Das zeigt bei mir mehr als 30 nicht aktualisierte Pakete an, obwohl ich kurz davor erst alles aktualisiert hab, mit:

```
# emerge -uDNva world
```

Einige der nicht-aktualisierten Pakete stehen sogar im world-File. 

z.B.

app-accessibility/festival

app-cdr/cdrkit

app-cdr/graveman

Andere sind Abhänigkeiten von installierten Programmen, darunter z.B. so prominente Vertreter wie

x11-base/xorg-x11  (installiert 7.1, es gibt aber 7.2)

x11-apps/xdm

x11-libs/gtk+

app-admin/sudo

Zu den im World-File vorhandenen Paketen:

Irgendwie sind eix Packete bekannt, welche Portage nicht kennt  :Shocked: 

```
# eix cdrkit

[U] app-cdr/cdrkit

     Available versions:  1.1.2 ~1.1.4 ~1.1.5.1 ~1.1.6

     Installed versions:  1.0(20:27:24 06/25/07)

     Homepage:            http://cdrkit.org/

     Description:         A suite of programs for recording CDs and DVDs, blanking CD-RW media, creating ISO-9660 filesystem images, extracting audio CD data, and more.

# emerge -s cdrkit

Searching...   

[ Results for search key : cdrkit ]

[ Applications found : 1 ]

 

*  app-cdr/cdrkit

      Latest version available: 1.0

      Latest version installed: 1.0

      Size of files: 1,435 kB

      Homepage:      http://cdrkit.org/

      Description:   A suite of programs for recording CDs and DVDs, blanking CD-RW media, creating ISO-9660 filesystem images, extracting audio CD data, and more.

      License:       GPL-2 LGPL-2.1

```

Wie kommt das zustande?

Zu den Paketen nicht im World-File:

Wenn ich die per Hand im World-File einfüge (z.B. x11-base/xorg-x11) und dann nach ein "emerge -uDNva world" mache wird dieses Paket und eine Abhängigkeit aktualisiert. Das sollte aber doch bei der Option -D (--deep) auch passieren ohne extra in world eingetragen zu sein?! Dafür ist diese Option doch da.

PS: keines der Pakete ist in /etc/portage/package.[keywords|mask|unmask]

----------

## forrestfunk81

Soooo....

einmal world-file aufräumen (und ergänzen)

emerge --depclean

revdep-rebuild und 

emerge -uDNva world

später konnte ich also die Anzahl der laut "eix -u" nicht aktualisierten Pakete auf 13 reduzieren (zuvor 32).

Die verbleibenden nicht aktuellen Pakete setzen sich folgendermaßen zusammen:

3 geslottete Packete

6 Pakete, von welchen eix schon neuere Versionen kennt, emerge -s aber nur die installierten Versionen kennt

4 Packete die tatsächlich, laut eix und laut emerge -s nicht aktuell sind

Also das mit den geslotteten Packeten ist klar.

Wieso eix teilweise neuere Packete kennt als emerge -s ist schon etwas seltsam.

Wenn ich diese Pakete in package.keywords eintrage, würde emerge -u <paket> dieses Paket auf die Version updaten, welche bei eix schon (ohne keywords-Eintrag) als stable gekennzeichnet ist.

Ich hab folgende Versionen drauf: eix 0.8.8, portage 2.1.2.9, beides stable auf amd64 (ein update von eix auf ~0.9.9 hat auch nix geändert)

Und zu den nicht aktuellen Packeten:

```

# emerge --update --deep world

Calculating world dependencies... done!

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

```

Komischerweise würden diese Pakete aber bei einem komplett Neubau aller Packete geupdated:

```
# emerge -ep world | grep U

[ebuild   R   ] virtual/perl-Scalar-List-Utils-1.19  

[ebuild   R   ] perl-core/Scalar-List-Utils-1.19  

[ebuild   R   ] dev-perl/URI-1.35  

[ebuild     U ] x11-misc/icon-naming-utils-0.8.2 [0.8.1] 

[ebuild     U ] dev-java/xjavac-20041208-r5 [20041208-r4] 

[ebuild     U ] www-client/lynx-2.8.6-r2 [2.8.6-r1] LINGUAS="-ja%" 

[ebuild     U ] app-admin/sudo-1.6.8_p12-r1 [1.6.8_p9-r2]
```

Ein

```
# emerge -1va x11-misc/icon-naming-utils dev-java/xjavac www-client/lynx app-admin/sudo

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ] x11-misc/icon-naming-utils-0.8.2 [0.8.1] 65 kB 

[ebuild     U ] dev-java/xjavac-20041208-r5 [20041208-r4] 0 kB 

[ebuild     U ] www-client/lynx-2.8.6-r2 [2.8.6-r1] USE="ipv6 nls ssl unicode -bzip2 -cjk" LINGUAS="-ja%" 2,238 kB 

[ebuild     U ] app-admin/sudo-1.6.8_p12-r1 [1.6.8_p9-r2] USE="offensive pam -ldap (-selinux) -skey" 572 kB 

Total: 4 packages (4 upgrades), Size of downloads: 2,875 kB

Would you like to merge these packages? [Yes/No] 

```

hilft da zwar auch, aber das sollte doch mit emerge --update --deep world automatisch gehen.

Hat da vllt jemand ne Erklärung?

----------

## Necoro

 *forrestfunk81 wrote:*   

> Hat da vllt jemand ne Erklärung?

 

update world ist komisch ... ich habe es für mein Programm teilweise nach implementiert - und naja --- ich habe nie komplett verstanden wie es was genau macht. Ich habe auch öfters beobachtet, dass meine einfache Methode mehr Pakete zum updaten raussucht als emerge -u world. Keine Ahnung ob das jetzt ein Bug oder ein Feature ist...

----------

## misterjack

Das gleiche ist mir auch gerade aufgefallen, hat da jemand eine Erklärung dafür?

```
misterjack ~ # emerge -avuDN world

These are the packages that would be merged, in order:

Calculating world dependencies           ... done!             

Total: 0 packages, Size of downloads: 0 kB

Nothing to merge; would you like to auto-clean packages? [Yes/No] 

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.
```

```
misterjack ~ # emerge -av1 virtual/perl-Test-Simple

These are the packages that would be merged, in order:

Calculating dependencies                                            ... done!

[ebuild     U ] perl-core/Test-Simple-0.70 [0.66] 76 kB 

[ebuild     U ] virtual/perl-Test-Simple-0.70 [0.66] 0 kB 

Total: 2 packages (2 upgrades), Size of downloads: 76 kB

Would you like to merge these packages? [Yes/No] 
```

----------

## tamiko

Ich schließe mich meinen Vorrednern mal an:

```
$ emerge -uDNp world

These are the packages that would be merged, in order:

Calculating world dependencies... done!
```

```
$ eix -u

[U] dev-lang/yasm

[...]

[U] x11-misc/makedepend

[...]

Found 2 matches.
```

```
$ emerge -1p yasm

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ] dev-lang/yasm-0.6.1 [0.6.0] 
```

----------

## Inte

Hihi, das makedepend hab ich auch. Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren?

$ equery d makedepend

media-libs/mesa-6.5.2-r1 (x11-misc/makedepend)

Mal nachschauen ... DEPEND="x11-misc/makedepend"

$ equery sys-apps/ed

x11-libs/libXaw-1.0.3 (sys-apps/ed)

Mal nachschauen ... DEPEND="sys-apps/ed"

Richtig vermutet! Die Pakete stehen ohne Versionsangabe als buildtime Abhängigkeit drin. Ein erneutes installieren mittels emerge -pvuDN von media-libs/mesa oder x11-libs/libXaw zieht auch nicht die neuen Versionen nach.

----------

## nikaya

Portage kennt als Sets ja nur "system" und "world".Pkgcore und Paludis haben noch andere Sets als default und zudem die Möglichkeit eigene Sets zu definieren.

Pkgcore hat z.B. das Set "installed":

 *http://www.pkgcore.org/trac/pkgcore/doc/doc/getting-started.rst wrote:*   

> 
> 
> Sets
> 
> Available sets are dependent upon your configuration. The majority of users still use /etc/make.conf configuration, which has five default sets:
> ...

 

Paludis kennt das Set "everything"

 *http://paludis.pioto.org/sets.html wrote:*   

> 
> 
> Formal Set Description
> 
> Internally, a set is a name with an associated dependency-style specification. In most cases the dependency specification will be an 'all-of' collection of package dependencies, although this is not a hard restriction.
> ...

 

Es kann also durchaus wohl Pakete geben welche kein Update benötigen wegen system oder world.

----------

## misterjack

 *Inte wrote:*   

> Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren?

 

Alles klar, dann ist es ja halbsowild  :Smile: 

----------

## tamiko

 :Very Happy: 

Darauf hätte ich kommen können, wenn ich nur eine Sekunde lang mal nachgeschaut hätte, was für Pakete er bei mir nicht aktualisieren wollte.

Mal wieder etwas dazugelernt.

----------

## TheSmallOne

 *Inte wrote:*   

> Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren?

 

Warum werden denn eigentlich Programme, die nur zum compilieren von anderen Programmen gebraucht werden, nicht wieder aus dem System entfernt, wenn der emerge-Vorgang abgeschlossen ist?

Das würde ich jedenfalls als default erwarten um das System nicht zumüllen zu lassen.

----------

## schachti

 *Inte wrote:*   

> Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren?

 

Zumindest sollten sie doch dann mit aktualisiert werden, wenn das Paket, das die dependencies benötigt, selbst aktualisiert wird, oder? (sorry für das gruselige Denglisch)

----------

## nikaya

 *schachti wrote:*   

>  *Inte wrote:*   Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren? 
> 
> Zumindest sollten sie doch dann mit aktualisiert werden, wenn das Paket, das die dependencies benötigt, selbst aktualisiert wird, oder? (sorry für das gruselige Denglisch)

 

Wer die dependencies aktualisiert haben möchte trage in die make.conf folgendes ein:

```
EMERGE_DEFAULT_OPTS="--with-bdeps y"
```

 *man emerge wrote:*   

> 
> 
> --with-bdeps < y | n > 
> 
> In dependency calculations, pull in build time dependencies that are not strictly required. This defaults to 'n' for installation actions and 'y' for the --depclean action. This setting can be added to EMERGE_DEFAULT_OPTS (see make.conf(5)) and later overridden via the command line.

 

----------

## Necoro

 *TheSmallOne wrote:*   

>  *Inte wrote:*   Kann es sein, dass das buildtime-dependencies sind? Wenn die nur zum bauen benötigt werden, warum sollte man die dann auch aktualisieren? 
> 
> Warum werden denn eigentlich Programme, die nur zum compilieren von anderen Programmen gebraucht werden, nicht wieder aus dem System entfernt, wenn der emerge-Vorgang abgeschlossen ist?
> 
> Das würde ich jedenfalls als default erwarten um das System nicht zumüllen zu lassen.

 

Weil du vielleicht nicht bei jedem emerge vorgang automake/autoconf neu bauen willst?  :Smile:  Oder die ganzen *proto teile vom xorg?

Wenn du sie loswerden willst, machst du ein:

```
emerge --depclean -a --with-bdeps=n
```

Das "--with-bdeps=n" sagt ihm, dass du die bdeps nicht behalten willst  :Smile: . Wichtig: Bei einigen Paketen stimmt die Unterscheidung nicht ganz ... teilweise sind da RDEPENDS als normale DEPENDS eingetragen (aiksaurus bei lyx zB), so dass da evtl was nicht mehr will danach

----------

## TheSmallOne

 *Necoro wrote:*   

> Weil du vielleicht nicht bei jedem emerge vorgang automake/autoconf neu bauen willst?  Oder die ganzen *proto teile vom xorg?

 

Gehören automake und autoconf nicht sowieso zum system-profil?

Wie auch immer: Warum denn nicht? Ich würde mal sagen, das hängt vom einzelnen System ab. Sicherlich macht es kaum Sinn, das alles jedesmal neu zu kompilieren, wenn jemand sein System täglich auf den neuesten Stand bringt, aber für jemanden, der vielleicht nur ein mal im Monat ein emerge -uD world auffüht macht es m.E. viel weniger Sinn für 30 Tage lang irgendwelche Software auf dem Rechner rumliegen zu haben, die niemand braucht.

----------

## Necoro

 *TheSmallOne wrote:*   

>  *Necoro wrote:*   Weil du vielleicht nicht bei jedem emerge vorgang automake/autoconf neu bauen willst?  Oder die ganzen *proto teile vom xorg? 
> 
> Gehören automake und autoconf nicht sowieso zum system-profil?]

 

Schon - aber jeweils nur eine Version .. und in der Regel hat man ja ungefähr .... 16 Myriaden Versionen von den autotools drauf  :Wink: 

Und wen die Dependencies stören - nun ja -- hindert ihn ja niemand, ein depclean durchlaufen zu lassen, wie in meinem Post beschrieben

----------

