# emerge world -Dvua: Updates werden nicht angezeigt

## NightDragon

Morgen zusammen!

Ich habe im Zuge des expat und curl Updates natürlich gleich das ganze System upgedated.

Dabei ist mir aufgefallen, dass extrem viele Updates fehlen.

Normalerweise müsste ich doch mit emerge world -Dvua alle Updates haben, oder?

Nun ist es so, dass ich vor 1 Jahr bei KDE die splited ebuilds verwendet habe (mergen mittels kde-meta, etc..).

Wenn ich aber jetzt emerge kde-meta -Dvua laufen lasse, bekomme ich mehr Pakete zum Updaten präsentiert, als mit world.

Warum ist das so?

Ich habe extra die splited ebuilds verwendet, weil ich selektiv einige Programme nicht brauche (z bsp. kmail).

Und jetzt muss ich ein Update mittels kde-meta machen, damit KDE wieder vollständig läuft. 

Was stimmt hier nicht?

----------

## forrestfunk81

Ich bin vor ein paar Wochen auch über sowas ähnliches gestolpert. 

Einige der nicht aktualisierten Pakete (anfangs über 30) waren auf eigene Fehler zurückzuführen. Aber am Schluss blieben immerhin 4 Pakete, welche nicht automatisch aktualisiert wurden (ich mache nahezu jeden Tag emerge -uDNva world). Habe dazu auch leider keine Erklärung gefunden.

Edit:

Hab mal wieder auf meinem System nach nicht aktuellen Paketen gesucht. Ausgangspunkt war ein *aktuelles* System:

```
ground0 ~ # emerge -uDNva 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] y

>>> Auto-cleaning packages...

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

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

```

Eix suche nach nicht aktuellen Paketen:

```
# eix -u

.....

Found 31 matches.
```

Da waren wieder einige slottet Pakete dabei, einige bei denen Eix schon neuere Pakete als stable markiert hat als Portage und 11 tatsächlich nicht aktuelle Pakete.

Letztes mal hat ein emerge -ep world | grep U gereicht, um die zu aktualisierenden Pakete anzuzeigen, aber diesmal fehlen da einige:

```
ground0 ~ # 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 ] dev-java/xjavac-20041208-r5 [20041208-r4] 

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

ground0 ~ #  emerge -va app-admin/sudo dev-cpp/gtkmm dev-java/xjavac gnome-base/eel gnome-base/gnome-desktop gnome-base/gnome-menus gnome-base/libgtop gnome-base/nautilus x11-libs/libgksu x11-libs/libxklavier www-client/lynx

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

Calculating dependencies... done!

[ebuild  N    ] dev-cpp/cairomm-1.2.4  USE="-doc -examples" 568 kB 

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

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

[ebuild     U ] gnome-base/eel-2.18.0.1 [2.16.3] USE="X -debug" 658 kB 

[ebuild     U ] gnome-base/gnome-desktop-2.18.2 [2.16.3] USE="-debug -doc" 0 kB 

[ebuild     U ] gnome-base/gnome-menus-2.18.2 [2.16.1] USE="python%* -debug" 427 kB 

[ebuild     U ] gnome-base/libgtop-2.14.9 [2.14.8] USE="X gdbm -debug" 755 kB 

[ebuild     U ] gnome-base/nautilus-2.18.1-r1 [2.16.3] USE="X -beagle -debug -gnome" 0 kB 

[ebuild     U ] x11-libs/libgksu-2.0.4 [2.0.0] USE="nls -debug -doc" 0 kB 

[ebuild     U ] x11-libs/libxklavier-3.2 [3.1] USE="-doc" 456 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 ] dev-cpp/gtkmm-2.10.9 [2.8.3] USE="-accessibility% -debug -doc% -examples%" 8,330 kB 

Total: 12 packages (11 upgrades, 1 new), Size of downloads: 14,000 kB

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

Naja.. irgendwie ist Portage da nicht so ganz durchschaubar, nach welchem Muster es die zu aktualisierenden Pakete auswählt.

----------

## NightDragon

Ich weiß, dass ich das Problem früher hatte, wo ich den Parameter -D (steht für Deep) vergessen hatte. Aber nachdem ich so wie du, fast immer emerge world -Dvua eingebe, sollte eigentlich alles gelistet werden.

Erklärung ist mir dazu auch noch keine eingefallen. Normal finde ich es auf jedenfall nicht.

----------

## Finswimmer

Teste bitte mal: emerge -nav1 `qlist -IC`

Gibt es da nen Unterschied?

----------

## Necoro

Versuch mal 

```
emerge -avNDu world --with-bdeps=y
```

. Ich glaube, mal gelesen zu haben, dass Build-Dependencies nur noch upgegradet werden, wenn sie explizit in einer neuen Version verlangt werden.

----------

## NightDragon

@ Finswimmer:

Ja es gibt Unterschiede und das doch starke:

emerge -nav1 `qlist -IC`

```
emerge -nav1 `qlist -IC`

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

Calculating dependencies... done!

[ebuild  N    ] dev-java/relaxng-datatype-1.0-r1  USE="source -doc" 73 kB

[ebuild  N    ] app-admin/eselect-emacs-1.1  7 kB

[ebuild  N F  ] dev-java/sun-jms-1.1-r2  USE="-doc" 354 kB

[ebuild  N    ] dev-java/sun-jaf-1.1  USE="source -doc" 33 kB

[ebuild  N    ] dev-java/javacc-4.0-r4  USE="source -doc -examples -test" 748 kB

[ebuild  N    ] dev-java/saxpath-1.0-r2  USE="source -doc -test" 2,116 kB

[ebuild  N    ] dev-java/tagsoup-1.1  USE="source -doc" 212 kB

[ebuild  N    ] dev-java/icu4j-3.0-r1  USE="source -doc" 8,778 kB

[ebuild  N    ] dev-java/iso-relax-20050331-r1  USE="source" 681 kB

[ebuild  N    ] dev-java/xpp2-2.1.10-r1  USE="source -doc" 2,257 kB

[ebuild  N    ] dev-java/xpp3-1.1.4c  USE="source -doc -test" 938 kB

[ebuild  N    ] dev-java/xmldb-20011111-r1  USE="source -doc" 36 kB

[ebuild  NS   ] gnome-extra/gtkhtml-3.14.3  USE="-debug -static" 1,254 kB

[ebuild  N    ] mail-filter/spamassassin-3.2.1-r1  USE="berkdb ipv6 ldap mysql postgres ssl tools -doc -qmail -sqlite" 959 kB

[ebuild     U ] app-accessibility/speech-tools-1.2.95_beta-r1 [1.2.3-r2] USE="X%* -esd% (-doc%)" 1,252 kB

[ebuild     U ] app-arch/cabextract-1.2 [1.1] 190 kB

[ebuild     U ] app-arch/unshield-0.5-r1 [0.5] 319 kB

[ebuild     U ] app-text/acroread-7.0.9-r1 [7.0.8] USE="cups ldap nsplugin* (-nls%*)" LINGUAS="de en%* -da% -es% -fi% -fr -it% -ja -ko -nb% -nl% -pt% -sv% -zh_CN -zh_TW" 91,362 kB

[ebuild  NS   ] app-text/docbook-sgml-dtd-4.4  66 kB

[ebuild  NS   ] dev-java/commons-beanutils-1.7.0-r2  USE="source -doc" 253 kB

[ebuild  NS   ] dev-java/commons-lang-2.1-r1  USE="source -doc" 366 kB

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

[ebuild     U ] dev-libs/zziplib-0.13.49 [0.13.45] USE="sdl" 640 kB

[ebuild     U ] dev-perl/Archive-Zip-1.20 [1.18] 173 kB

[ebuild     U ] dev-python/dnspython-1.5.0 [1.3.5] USE="-examples%" 97 kB

[ebuild     U ] dev-util/gtk-doc-1.8-r2 [1.6-r1] USE="-debug -doc -emacs" 182 kB

[ebuild     U ] dev-util/indent-2.2.9-r3 [2.2.9-r2] USE="nls" 663 kB

[ebuild     U ] dev-util/jam-2.5-r3 [2.5] 610 kB

[ebuild     U ] mail-client/mailx-8.1.2.20050715-r1 [8.1.2.20040524-r1] 129 kB

[ebuild     U ] mail-client/mailx-support-20060102-r1 [20030215] 9 kB

[ebuild     U ] media-libs/glew-1.3.5 [1.3.3] 382 kB

[ebuild     U ] media-libs/libsvg-0.1.4 [0.1.2] 359 kB

[ebuild     U ] media-plugins/gst-plugins-esd-0.10.3 [0.10.2] 1,139 kB

[ebuild     U ] media-plugins/gst-plugins-oss-0.10.3 [0.10.2] 0 kB

[ebuild     U ] net-libs/liblockfile-1.06-r2 [1.06-r1] 32 kB

[ebuild     U ] x11-apps/sessreg-1.0.2 [1.0.0] USE="-debug" 93 kB

[ebuild     U ] x11-apps/xdm-1.1.4 [1.0.5] USE="ipv6 pam xprint -debug" 378 kB

[ebuild     U ] x11-drivers/xf86-video-i810-1.7.4 [1.7.0-r1] USE="dri -debug" 452 kB

[ebuild     U ] x11-libs/gtkglext-1.2.0 [1.0.6-r3] USE="-debug -doc" 688 kB

[ebuild     U ] x11-libs/libXevie-1.0.2 [1.0.1] USE="-debug" 223 kB

[ebuild     U ] x11-libs/libxklavier-3.2 [3.1] USE="-doc" 456 kB

[ebuild     U ] x11-wm/metacity-2.18.5 [2.16.3] USE="xinerama -debug (-xcomposite%*)" 1,904 kB

[ebuild  N    ] dev-java/xsdlib-20050627-r1  USE="source -doc" 786 kB

[ebuild  N    ] dev-java/jaxme-0.3.1-r4  USE="source -doc" 2,988 kB

[ebuild  N    ] dev-java/sun-javamail-1.4  USE="source -doc" 282 kB

[ebuild  N    ] dev-java/jdom-1.0-r2  USE="source -doc -examples" 3,489 kB

[ebuild  N    ] dev-java/xom-1.0-r2  USE="source -doc" 3,317 kB

[ebuild     U ] app-editors/xemacs-21.4.20-r4 [21.4.20-r1] USE="X Xaw3d* berkdb gdbm gif gpm jpeg ldap motif nas png postgres tiff -athena -canna -dnd -eolconv -esd -freewnn -mule -neXt -pop -xface -xim%" 8,251 kB

[ebuild  NS   ] dev-java/lucene-2.1.0  USE="source -doc -test" 7,964 kB

[ebuild     U ] mail-client/evolution-2.10.2 [2.8.3-r2] USE="crypt dbus hal ipv6 kerberos krb4 ldap mono pda spell ssl -bogofilter -debug -doc -nntp -profile" 21,625 kB

[ebuild  N    ] dev-java/msv-20050627-r1  USE="source -doc" 3,703 kB

[ebuild  N    ] dev-java/jsr173-1.0-r1  USE="source -doc" 625 kB

[ebuild  NS   ] dev-java/avalon-logkit-2.1-r1  USE="source -doc -test" 59 kB

[ebuild  N    ] dev-java/dom4j-1.6.1-r2  USE="source -doc" 9,463 kB

[ebuild  N    ] dev-java/jaxen-1.1.1  USE="source -doc -examples -test" 265 kB

[ebuild  N    ] dev-java/xml-xmlbeans-1.0.4_pre20041217  USE="source -doc" 2,380 kB

[ebuild  NS   ] dev-java/rhino-1.6.1-r3  USE="source -doc" 1,724 kB

Total: 57 packages (27 upgrades, 23 new, 7 in new slots), Size of downloads: 187,756 kB

Fetch Restriction: 1 package (1 unsatisfied)

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

Exiting on signal 2
```

Und das schon bekannte Ergebnis von emerge world -Dvu:

```
emerge world -Dvua

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]

Exiting on signal 2
```

@ Necoro:

Deine Angabe liefert mir massenweise installierte Ebuilds und nur 4 Updates.

Jetzt würde ich dennoch gern wissen, was hier abgeht. Das kanns ja dann wirklich nicht sein....

(danke für die Hilfe Leute!)

----------

## Finswimmer

Also...qlist -IC listet jedes einzelne Paket auf, welches installiert ist, also auch alle Abhängigkeiten. Diese werden auf Updates getestet und wenn vorhanden, installiert.

emerge world -Dvu:

beinhaltet folgenden Fehler: --newuse felht.

Das bedeutet, dass geänderte Use Flags erst bei einem Versionssprung erkannt/umgesetzt werden.

Das wäre bei dir schonmal die Erklärung für 4 Pakte.

Bei dem Rest ist es wohl dass sie nicht in der World/System Datei stehen, sondern reine Abhängigkeiten sind.

Warum diese wiederum nicht richtig überprüft werden (wenn es mit meinem Einzeiler schon so einfach geht) weiß ich nicht.

Tobi

----------

## Necoro

 *Finswimmer wrote:*   

> Bei dem Rest ist es wohl dass sie nicht in der World/System Datei stehen, sondern reine Abhängigkeiten sind.
> 
> Warum diese wiederum nicht richtig überprüft werden (wenn es mit meinem Einzeiler schon so einfach geht) weiß ich nicht.
> 
> 

 

Wie ich schon sagte - ich glaube, dass Build-Dependencies (also solche die im ebuild in DEPEND stehen) nicht aktualisiert werden (warum auch - DEPEND bedeutet, dass man sie braucht um das Paket zu kompilieren -- wenn es schon kompiliert ist macht es ja keinen Sinn sie regelmäßig upzudaten)...

Andererseits glaube ich nicht, dass "acroread" und "evolution" in irgendeinem DEPEND auftauchen ... warum diese also nicht aktualisiert werden ist mir ein Rätsel ... @Nightdragon: stehen diese Pakete im worldfile?

----------

## Mr. Anderson

```
emerge -nav1 `qlist -IC`

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

Calculating dependencies... done!

[ebuild  N    ] dev-java/javacc-4.0-r4  USE="-doc -examples -source -test" 748 kB

[ebuild  NS   ] dev-libs/apr-1.2.8  USE="-debug -ipv6 -urandom" 1,082 kB

[ebuild  NS   ] app-text/docbook-sgml-dtd-4.4  66 kB

[ebuild  NS   ] app-text/docbook-xml-dtd-4.4-r1  94 kB

[ebuild  NS   ] dev-java/lucene-2.1.0  USE="-doc -source -test" 7,964 kB

[ebuild  NS   ] dev-libs/apr-util-1.2.8  USE="berkdb gdbm ldap -postgres -sqlite -sqlite3" 632 kB

Total: 6 packages (1 new, 5 in new slots), Size of downloads: 10,583 kB
```

Diese Pakete sind IMO aber alle nicht notwendig. Zum Beispiel ist apr in Version 0.9.12 installiert, da Apache 2.0.58-r2 als Abhängigkeit =dev-libs/apr-0* reinzieht. Klar, wenn ich emerge -p apr eingebe, wird mir mitgeteilt, dass ein Update erfolgen würde. Alles was es bringt ist aber eine zusätzlich installierte Version. Außer Apache und seinen Abhängigkeiten will kein Paket apr. Das Paket läge also nur unnütz auf der Festplatte.

Auch Portage ist dieser Ansicht ^^

```
emerge world -uDNav --with-bdeps y

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

Calculating world dependencies... done!

Total: 0 packages, Size of downloads: 0 kB
```

----------

## UTgamer

 *Finswimmer wrote:*   

> Teste bitte mal: emerge -nav1 `qlist -IC`
> 
> Gibt es da nen Unterschied?

 

Ich wollte dies auch mal ausprobieren, nach dem ich noch 8 weitere KDE-3.5.7 Ebuilds für diesen Test maskieren mußte, hängt der jetzt z.B. an 

```
- www-client/mozilla-firefox-2.0.0.6 (masked by: package.mask)

- www-client/mozilla-firefox-2.0.0.4 (masked by: package.mask)

- www-client/mozilla-firefox-1.5.0.10 (masked by: package.mask)

# RaÃºl Porcel <armin76@gentoo.org> (13 Aug 2007)

# Vulnerable, unsupported, was supposed to go away

# some months ago, pending removal in 15 days

- www-client/mozilla-firefox-1.5.0.7 (masked by: package.mask)

- www-client/mozilla-firefox-1.5.0.12 (masked by: package.mas
```

fest.

Ich brauche den 1.5er FF jedoch für Javascripttests, zum eigentl. surfen verwende ich ja auschließlich Seamonkey. Ich habe alle 2.x FF Versionen selbst gemasked. die 1.5.0.12 Version schon seit Monaten in meinem Overlay als noch unmaskiert, hier bei der vorgeschlagen Methode emerge -nav1 `qlist -IC` werden anscheinend die Overlays ignoriert,  und da habe ich noch einige Programme drinn. Wird also nicht bei jedem funktionieren.  :Sad: 

Weitere Methoden sind willkommen.

----------

## Mr. Anderson

 *UTgamer wrote:*   

>  *Finswimmer wrote:*   Teste bitte mal: emerge -nav1 `qlist -IC`
> 
> Gibt es da nen Unterschied? 
> 
> Ich wollte dies auch mal ausprobieren, nach dem ich noch 8 weitere KDE-3.5.7 Ebuilds für diesen Test maskieren mußte, hängt der jetzt z.B. an 
> ...

 

Vielleicht würde sich bei Dir ein emerge --depclean lohnen.

 *Necoro wrote:*   

> Andererseits glaube ich nicht, dass "acroread" und "evolution" in irgendeinem DEPEND auftauchen ... warum diese also nicht aktualisiert werden ist mir ein Rätsel ... @Nightdragon: stehen diese Pakete im worldfile?

 

```
$ grep DEPEND /usr/portage/media-fonts/acroread-asianfonts/acroread-asianfonts-7.0.8.ebuild

DEPEND=">=app-text/acroread-7.0.8"
```

```
$ grep -iR mail-client/evolution /usr/portage/*

...

app-pda/multisync/multisync-0.83_pre20050414-r4.ebuild:         evo?  ( mail-client/evolution )

app-pda/multisync/multisync-0.83_pre20050414-r4.ebuild:         evoversion="$(best_version mail-client/evolution)"

gnome-base/gnome/gnome-2.18.2-r1.ebuild:        >=mail-client/evolution-2.10.2

gnome-base/gnome/gnome-2.16.3.ebuild:   >=mail-client/evolution-2.8.3

gnome-extra/evolution-exchange/evolution-exchange-2.6.2-r1.ebuild:RDEPEND=">=mail-client/evolution-2.5.90

gnome-extra/evolution-exchange/evolution-exchange-2.10.1.ebuild:RDEPEND=">=mail-client/evolution-2.10

gnome-extra/evolution-exchange/evolution-exchange-2.8.3.ebuild:RDEPEND=">=mail-client/evolution-2.7

mail-client/mail-notification/mail-notification-4.0_rc2.ebuild: evolution? ( >=mail-client/evolution-2.6 )

mail-client/mail-notification/mail-notification-4.0_rc2.ebuild:         EVO_INSTALLED="$(best_version mail-client/evolution)"

mail-client/mail-notification/mail-notification-2.0.ebuild:     evolution? ( >=mail-client/evolution-2.4 )

mail-client/mail-notification/mail-notification-2.0.ebuild:             EVO_INSTALLED="$(best_version mail-client/evolution)"

mail-client/mail-notification/mail-notification-3.0.ebuild:     evolution? ( >=mail-client/evolution-2.4 )

mail-client/mail-notification/mail-notification-3.0.ebuild:             EVO_INSTALLED="$(best_version mail-client/evolution)"

mail-client/mail-notification/mail-notification-4.0.ebuild:     evolution? ( >=mail-client/evolution-2.6 )

mail-client/mail-notification/mail-notification-4.0.ebuild:             EVO_INSTALLED="$(best_version mail-client/evolution)"

...

net-mail/lbdb/lbdb-0.34.ebuild: evo? ( mail-client/evolution )

net-mail/lbdb/lbdb-0.34.ebuild:         evoversion=$(best_version mail-client/evolution)

net-mail/lbdb/lbdb-0.34.ebuild:         evoversion=${evoversion##mail-client/evolution-}

net-mail/lbdb/lbdb-0.35.1.ebuild:       evo? ( mail-client/evolution )

net-mail/lbdb/lbdb-0.35.1.ebuild:               evoversion=$(best_version mail-client/evolution)

net-mail/lbdb/lbdb-0.35.1.ebuild:               evoversion=${evoversion##mail-client/evolution-}

...
```

 :Wink: 

----------

## UTgamer

 *Mr. Anderson wrote:*   

>  *UTgamer wrote:*    *Finswimmer wrote:*   Teste bitte mal: emerge -nav1 `qlist -IC`
> 
> Gibt es da nen Unterschied? 
> 
> Ich wollte dies auch mal ausprobieren, nach dem ich noch 8 weitere KDE-3.5.7 Ebuilds für diesen Test maskieren mußte, hängt der jetzt z.B. an 
> ...

  Mein System ist zwar erst 2 Monate alt und 8 kleine Abhängigkeiten wurden entfernt, jedoch am Resultat das ältere Anwendungen die ich noch in Overlays habe nicht akzeptiert werden hat sich leider nichts geändert. Da habe ich also den älteren Firefox und Thunderbird (beide installiert), das neue Openoffice da das Original nicht gebaut werden kann wegen Portagebug, gnustep, zur Vorsicht KDE-3.5.5 und Blackdown-java wegen des 64bit Plugins, ältere Udevs für Testzwecke (nicht installiert), ältere Kernelsources zum Testen sowie Mozilla-1.7.11 zum Testen von Webanwendungen (nicht installiert). Warum er aber jetzt am Firefox hängen bleibt, ka.

Portage hat eben leider noch seine Bugs, wie z.B. der eben aufgeführte.

----------

## Mr. Anderson

Sollte der Firefox als Abhängigkeit reingezogen werden, müsste das ja dabeistehen, dass er als Abhängigkeit von xy benötigt wird. Steht nichts dran?

Tritt das auch auf bei einem emerge -ep world?

Was macht emerge -ep mozilla-firefox?

----------

## UTgamer

```
emerge -ep world | more

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

!!! Ebuilds for the following packages are either all

!!! masked or don't exist:

net-im/pidgin www-client/mozilla-firefox net-libs/linc app-portage/gentoolkit-lefou

Calculating world dependencies  ..... ..... ..... ..... ..... ..... ..... ... done!

[ebuild   R   ] sys-apps/portage-2.1.2.11

[ebuild   R   ] ...
```

```
emerge -ep mozilla-firefox

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

Calculating dependencies |

!!! All ebuilds that could satisfy "mozilla-firefox" have been masked.

...
```

Sind schon etwas seltsam die Ergebnisse.

Aus der make.conf

```
#PORTDIR_OVERLAY="/usr/local/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/gnustep"

source /usr/portage/local/layman/make.conf
```

Ich glaube die ersten Fehler erhiehlt ich als ich das erste mal layman verwendet hatte, aber es war nur eine Eintragung von 

```

!!! Ebuilds for the following packages are either all

!!! masked or don't exist:
```

 Ohne das ein ebuild angegeben wurde, hatte ich dann auch ignoriert.

----------

## Finswimmer

Sicher, dass:

nicht alle FF Versionen gemasked sind

die 1.5er FF Versionen noch existieren?

----------

## NightDragon

 *Finswimmer wrote:*   

> Also...qlist -IC listet jedes einzelne Paket auf, welches installiert ist, also auch alle Abhängigkeiten. Diese werden auf Updates getestet und wenn vorhanden, installiert.
> 
> emerge world -Dvu:
> 
> beinhaltet folgenden Fehler: --newuse felht.
> ...

 

Aber genau das nervt mich an Gentoo. Jetzt z. bsp. findet revdep-rebuild nichts mehr.  Alle Updates sind durchgeführt und ich kann jedes Paket durchgehen um Apache wieder ans laufen zu bekommen.

Mir ist klar, dass reine Abhängigkeiten nicht installiert/geupdated werden, wenn diese nicht benötigt werden. Aber ich kann ja nicht jedes mal wenn einer bei Gentoo auf die Idee kommt eine wichtige Lib in neuer Version freizugeben, alles mit 20 Befehlen neu mergen. Da kann ich gleich emerge world -Dvuea eingeben. Dann hab ich das Problem nicht mehr.

Neue USE-Flags sind mir eher egal, die können langsam umgesetzt werden. Aber Bei KDE, darf das bitte sehr nicht sein.

Wieso muss ich KDE-Meta installieren, um alle KDE-Programme auf 3.5.7 zu aktualisieren? Ich mein, was bringt es mir wenn die META-Ebuilds die Abhängigkeiten nicht ins world-file eintragen? Wieso dann splitted ebuilds? 

Dann sind die Meta-Pakete ja völlig sinnlos. Ich hätte nämlich gern alle Pakete installiert und dann selektiv deinstalliert. Nicht anders rum... Und das ärgert mich dann wirklich.

@Necoro

Acroread genau wie evolution habe ich ganz normal gemergt und deswegen verstehe ich langsam nichts mehr.

Sorry wenn ich derzeit au 100 bin, aber das ärgert mich wieder. Und genau DAS sind die Dinge, wieso Gentoo NIE wirklich nach oben kommen wird.

Es muss nicht ein SuSe System sein, aber Gentoo sollte zumindest so eine Umstellung ohne hunderte von Workarounds und Bugfixes schaffen....

[EDIT]

Apache läuft wieder. Es gab natürlich apr und apr-utils in 2 Versionen. Damit gabs natürlich Probleme, weil die alten Versionen gegen die alten libexpat gelinkt wurden. Okay, es ist wieder mal ganz klar. Ich muss um sicherzugehen keine Sideeffects zu haben, das ganze System neu übersetzen. 

[/EDIT]

----------

## Finswimmer

Meta Ebuilds sind dafür da, dass man alle KDE Pakete installiert, also so wie es früher war.

Sie sind nicht dafür da, dass du dann Pakete wieder deinstallierst, weil du sie nicht haben willst.

Denn: Wenn nun das Meta Ebuild neu installiert wird, überprüft es ob alle Pakete da sind, das sind sie ja dann nicht. Daraufhin installiert es dir dann die Pakete wieder neu, die du eigentlich gar nicht haben willst.

Deswegen: Mach dir mal die Mühe und trag das ein, was du brauchst und lass den Meta Kram weg.

Oder: Stör dich nicht an 4-5 Pakete, die du nicht brauchst und sei glücklich mit den Metas.

Alles dazwischen wird nichts.

Tobi

----------

## NightDragon

 *Quote:*   

> Deswegen: Mach dir mal die Mühe und trag das ein, was du brauchst und lass den Meta Kram weg.
> 
> Oder: Stör dich nicht an 4-5 Pakete, die du nicht brauchst und sei glücklich mit den Metas.

 

Okay, dann verstehe ich den Unterschied zwischen den Meta-Paketen und den kompletten Paketen nicht.

Wieso soll ich mittels Meta-Pakete jedes KDE-Tool eigens installieren, wenn ich gleich die Großen verwenden kann?

Sprich wieso kde-meta wenn ich nur kde mergen kann ?

Ich habe gedacht das genau für das die Metas da sind. Weil so wie Du das erklärst, verstehe ich das so, dass die Metas nichts anderes machen, nur eben mit den splitted Ebuilds.

----------

## Finswimmer

kde-meta: installiert

$(deprange $PV $MAXKDEVER kde-base/kdeaddons-meta)

$(deprange $PV $MAXKDEVER kde-base/kdeadmin-meta)

$(deprange $PV $MAXKDEVER kde-base/kdebase-meta)

$(deprange $PV $MAXKDEVER kde-base/kdeedu-meta)

$(deprange $PV $MAXKDEVER kde-base/kdegames-meta)

$(deprange $PV $MAXKDEVER kde-base/kdegraphics-meta)

$(deprange $PV $MAXKDEVER kde-base/kdemultimedia-meta)

$(deprange $PV $MAXKDEVER kde-base/kdenetwork-meta)

kde installiert:

        ~kde-base/kdelibs-${PV}

        ~kde-base/kdebase-${PV}

        ~kde-base/kdeaddons-${PV}

        ~kde-base/kdeadmin-${PV}

        ~kde-base/kdeartwork-${PV}

        ~kde-base/kdeedu-${PV}

        ~kde-base/kdegames-${PV}

        ~kde-base/kdegraphics-${PV}

        ~kde-base/kdemultimedia-${PV}

        ~kde-base/kdenetwork-${PV}

        ~kde-base/kdepim-${PV}

Wenn ich nun alles bis auf Kmail haben will, müsste ich:

alle meta Pakete emergen, bis auf kdenetwork

Dann alle in Kdenetwort enthaltenen Pakete mergen bis auf kmail.

Denn sonst passiert dir das, was ich vorhin schon erläutert habe, dass bei einem Re-emerge von einem meta Paket plötzlich kmail auftaucht.

(Falls du also: emerge kde-meta;emerge -C kmail machst)

tobi

----------

## NightDragon

Also es ist ja klar, dass es nicht nur um kmail ging (War ja ein Beispiel, nicht die komplette Liste, etc...)

Ich finde nur mit der Zeit raus, was ich sicher nicht brauche. 

Viele Tools würde man vermutlich vermissen, wenn man nicht alles installiert. Ich kenne nicht von jedem KDE Tool den Namen. Aber wenn ich sehe was ich nicht brauche, kann ich es deinstallieren. kmail war eines davon.

Verstehst du wie ich meine?

Es muss ja mehr Sinn in den metas sein, als nur das.

----------

## UTgamer

 *Finswimmer wrote:*   

> Sicher, dass:
> 
> nicht alle FF Versionen gemasked sind
> 
> die 1.5er FF Versionen noch existieren?

 

Habe in der package.mask nur diesen Eintrag:

>=www-client/mozilla-firefox-2.0

----------

## Finswimmer

 *NightDragon wrote:*   

> Also es ist ja klar, dass es nicht nur um kmail ging (War ja ein Beispiel, nicht die komplette Liste, etc...)
> 
> Ich finde nur mit der Zeit raus, was ich sicher nicht brauche. 
> 
> Viele Tools würde man vermutlich vermissen, wenn man nicht alles installiert. Ich kenne nicht von jedem KDE Tool den Namen. Aber wenn ich sehe was ich nicht brauche, kann ich es deinstallieren. kmail war eines davon.
> ...

 

Ich versteh das schon, aber du verstehst auch, dass dir das eigentlich nichts bringt? Denn bei einem Meta-Re-Emerg ist ja alles wieder drauf.

Ne bessere Idee habe ich allerdings auch nicht.

Und mit Kmail war bei mir auch ein Beispiel  :Wink: 

----------

## nikaya

 *UTgamer wrote:*   

>  *Finswimmer wrote:*   Sicher, dass:
> 
> nicht alle FF Versionen gemasked sind
> 
> die 1.5er FF Versionen noch existieren? 
> ...

 

Die 1.5er mozilla-firefox Versionen sind alle hartmaskiert.

```
eix -e mozilla-firefox

* www-client/mozilla-firefox

     Available versions:  [M]1.5.0.7 [M]1.5.0.7[1] [M]1.5.0.10 [M]1.5.0.10[1] [M]1.5.0.12 [M]1.5.0.12[1] 2.0.0.2 2.0.0.2[1] 2.0.0.3 2.0.0.4 2.0.0.4[1] 2.0.0.5 2.0.0.6[1] [...]
```

und da Du alle Versionen >= 2 auch maskiert hast will Portage keinen Feuerfuchs installieren.Wenn es unbedingt der 1.5er sein muß packe ihn in ein eigenes Overlay.

----------

## UTgamer

 *nikaya wrote:*   

> ...
> 
> und da Du alle Versionen >= 2 auch maskiert hast will Portage keinen Feuerfuchs installieren.Wenn es unbedingt der 1.5er sein muß packe ihn in ein eigenes Overlay.

 

Er ist ja in einem Overlay  :Wink: 

----------

## NightDragon

@Finswimmer:

Ja das ist mir klar, ich dachte dass es genügt, wenn ich die meta merge, die metas selbst dann unmerge und dann einfach jedes mal update. Aber die Updates will er ohne metas nicht machen. Vermutlich weil bei den Metas die Ebuilds nicht in die World-Datei kommen.

----------

## Finswimmer

Richtig. Außer du machst es mit qlist -IC.

Was ja auch nicht stört...

----------

## NightDragon

Schaden nicht, aber es ist wieder ein Minus Punkt für Gentoo.

5 Jahre schon... und dann immer wieder sowas.

----------

## nikaya

 *UTgamer wrote:*   

> 
> 
> Er ist ja in einem Overlay 

 

Sorry,überlesen.  :Embarassed: 

Wäre interessant wie das Paket aus dem Overlay genau heißt.Wenn der Name identisch mit einer Version aus dem Gentoo Repo ist wird der package.mask Eintrag es auch wohl blocken.Du könntest das Ebuild umbenennen oder es in package.unmask eintragen.

----------

## UTgamer

 *nikaya wrote:*   

>  *UTgamer wrote:*   
> 
> Er ist ja in einem Overlay  
> 
> Sorry,überlesen. 
> ...

 

Der Name ist gleich. Ich glaube du hast die rettende Idee.  :Smile: 

Jetzt muß ich nur wieder die ganzen ebuilds abändern und digesten, gruml, ich kann mich nicht daran erinnern das dies früher auch schon so war.

----------

## Finswimmer

 *UTgamer wrote:*   

>  *nikaya wrote:*    *UTgamer wrote:*   
> 
> Er ist ja in einem Overlay  
> 
> Sorry,überlesen. 
> ...

 

Bei Paludis kannst du Pakete aus bestimmten Overlays blockieren.

Tobi

----------

## UTgamer

 *Finswimmer wrote:*   

> 
> 
> Bei Paludis kannst du Pakete aus bestimmten Overlays blockieren.
> 
> Tobi

 

Nett, aber in meinem Falle nicht das gleiche, ich will ja das es nicht weiter blockiert ist.  :Wink: 

----------

## nikaya

 *UTgamer wrote:*   

>  *Finswimmer wrote:*   
> 
> Bei Paludis kannst du Pakete aus bestimmten Overlays blockieren.
> 
> Tobi 
> ...

 

Natürlich kann man bei Paludis auch Pakete damit demaskieren.Dort werden Pakete nur eindeutiger zu Repositorien zugeordnet,wie z.B. www-client/mozilla-firefox::my_overlay.Zusätzlich kann man in den repository.conf files noch einen "importance" Eintrag aufnehmen.Damit kann man die Präferenzen von Repositories einstellen.

Aber ich bin immer noch guter Hoffnung dass Portage solche Sachen dank EAPI auch bald besser handhaben kann.  :Rolling Eyes: 

----------

## UTgamer

Wo ihr es erwähnt, ich könnte ja auch nach langer Zeit mal wieder ekeyword aus gentoolkit-dev verwenden, hatte es bereits solange nicht mehr eingesetzt das ich es glatt vergessen hatte.  :Wink: 

Aber merke schon, ihr meint ich solle unbedingt Paludis mal probieren, ihr Schlimmerchens   :Laughing: 

Mal sehen wann ich es probieren werde.

----------

## nikaya

 *UTgamer wrote:*   

> ekeyword aus gentoolkit-dev

 

Kurze Erklärung bitte.

----------

## UTgamer

 *nikaya wrote:*   

>  *UTgamer wrote:*   ekeyword aus gentoolkit-dev 
> 
> Kurze Erklärung bitte.

 

Ich habe das Tool bereits früher eingesetzt gehabt, nur solange nicht mehr verwendet das ich es einfach vergessen hatte. Ich mache mir eigentl. zu allem wichtigen Notizen.

```
emerge gentoolkit-dev
```

Dies ist eine alte Notiz von mir selbst:

 *Quote:*   

> 
> 
> # Mit ekeyword aus dem Paket gentoolkit-dev in Portage overlay selbst Pakete stable gesetzt:
> 
> # cd /usr/local/portage/...
> ...

 

Hilft dir das weiter?

----------

## nikaya

 *UTgamer wrote:*   

> 
> 
> Hilft dir das weiter?

 

Jo,jetzt weiß ich was der Sinn und Zweck ist.Werden damit direkt die ebuilds editiert oder macht das Tool Einträge in package.keywords?

Edit:

OK,habe gerade die manpage gelesen.Ist ein Tool für Devs um KEYWORDS in ebuilds zu ändern.

----------

## mv

 *NightDragon wrote:*   

> Wieso soll ich mittels Meta-Pakete jedes KDE-Tool eigens installieren, wenn ich gleich die Großen verwenden kann?

 

Weil so ein bugfix von z.B. kdeinit schnell eingespielt ist und nicht unbedingt benötigt, dass Du das gesamte kdebase-Paket neu übersetzt.

 *Quote:*   

> Sprich wieso kde-meta wenn ich nur kde mergen kann?

 

Wiel kde-meta eben heißt: Das gesamte kde, aber in Form von splitted ebuilds.

 *Quote:*   

> Vermutlich weil bei den Metas die Ebuilds nicht in die World-Datei kommen

 

Natürlich kommen nur die Metas selbst in die World-Datei. Es wäre ja auch ziemlicher Unfug, wenn beim Emergen eines Pakets plötzlich dessen gesamte direkte (oder im Fall von kde-meta sogar indirekte) Abhängigkeiten in der World-Datei landen würden.

Ich würde an Deiner Stelle mal die world Datei reparieren, sprich, dafür sorgen, dass nach einem emerge -De world genau die von Dir installierten Pakete angezeigt werden. Im Falle von kde kannst Du das z.B. so machen, indem Du manuell oder per Skript alle Abhängigkeiten (außer denen, die Du explizit nicht willst) aus den *-meta Paketen in die world Datei schreibst; anschließend kannst Du die entsprechenden Meta-Pakete unmergen (wenn Du nicht alles willst, war es eben eigentlich schon ein Fehler gewesen, die *-meta Pakete überhaupt zu emergen - das ist nur eine quick-and-dirty Lösung). Wenn Du im Moment dazu keine Zeit hast, kannst Du weiter mit quick-and-dirty pfuschen, und z.B. die kde-Pakete, die Du explizit nicht willst, nach dem unmergen in /etc/profile/etc/portage/profile/package.provided (mit Versionsnummer) eintragen. Aber wie gesagt, das ist nur ein Hack, wenn Du im Moment knapp an Zeit bist - die saubere Lösung ist das explizite Eintragen der Pakete, die Du wirklich willst, in der world Datei und das Löschen der anderen Pakete.

----------

## NightDragon

 *mv wrote:*   

> 
> 
> Natürlich kommen nur die Metas selbst in die World-Datei. Es wäre ja auch ziemlicher Unfug, wenn beim Emergen eines Pakets plötzlich dessen gesamte direkte (oder im Fall von kde-meta sogar indirekte) Abhängigkeiten in der World-Datei landen würden. 

 

Das die Metas selbst im World file sind, weiß ich, dass die Abhängigkeiten speziell bei diesen Metas nicht im World-File stehen, wusste ich nícht:

Gentoo is about choice: Und daher dachte ich okay es wird ja mitgedacht worden sein, dass für die Umstellung der normalen auf die gesplitteden Ebuilds diese dann auch im World-File landen.

Das es bei anderen Packeten keinen Sinn machen würde, ist mir klar.

 *mv wrote:*   

> Ich würde an Deiner Stelle mal die world Datei reparieren, sprich, dafür sorgen, dass nach einem emerge -De world genau die von Dir installierten Pakete angezeigt werden. 

 

Danke für den Tipp, aber der Aufwand steht nicht dafür. Daher habe ich nun KDE komplett installiert lassen. Ich habe nicht die nötige Zeit mich damit rumzuschlagen.

 *mv wrote:*   

> wenn Du nicht alles willst, war es eben eigentlich schon ein Fehler gewesen, die *-meta Pakete überhaupt zu emergen - das ist nur eine quick-and-dirty Lösung

 

Ja das war mir schon klar was passiert. Nach 5 Jahren Gentoo weiß ich meist wies funktioniert. Meine Aussagen sind eher als Kritik anstelle von Unwissenheit zu sehen.

Ich bin selbst zertifizierter SW-Test-Engineer, und da stechen mir viele Dinge eben schnell ins Auge.

 *mv wrote:*   

> Wenn Du im Moment dazu keine Zeit hast, kannst Du weiter mit quick-and-dirty pfuschen, und z.B. die kde-Pakete, die Du explizit nicht willst, nach dem unmergen in /etc/profile/etc/portage/profile/package.provided (mit Versionsnummer) eintragen. Aber wie gesagt, das ist nur ein Hack, wenn Du im Moment knapp an Zeit bist - die saubere Lösung ist das explizite Eintragen der Pakete, die Du wirklich willst, in der world Datei und das Löschen der anderen Pakete.

 

Das wäre natürlich auch ein interessantes Workaround. Ich habe aber über die Aussagen weiter oben nachgedacht. Ich werde KDE komplett installiert lassen.

Status:

Danke nochmals für Eure Antworten Leute!!

Es gibt immer wieder einige Dinge die einfach zu wenig bekannt gemacht werden, die dann zu Problemen führen. Damals als die splitted-Ebuilds kamen, hatte ich die Metas als Migrationshilfe verstanden. Ich wollte ein KDE-System komplett installieren, die Metas rauswerfen und dann selektiv die ungewünschten Tools, Utils, etc... deinstallieren.

Ich ging davon aus, dass speziell bei den KDE-Metas die Abhängigkeiten eben schon eingetragen werden: FALSCH gedacht. Die Metas dienen also nicht als Hilfe bei Umstellung, wie damals angenommen, auch wenn es von vielen so verstanden wurde.

Warum ich jetzt wieder das höchste META installiert hab, liegt daran, dass ein funktionierendes System vor einem angepassten geht. (Prioritätensetzung)

Ich verzichte lieber darauf einige Tools deinstalliert zu haben, als KDE halb gebrochen wegen alten Libs zu haben.

Ich brauch keine weiteren Tipps dies bezüglich mehr. Das Problem ist für mich so gelöst und alle Unklarheiten sind beseitigt.

Sollte ich noch fragen haben, werd ichs schreiben  :Wink:  Nochmals Thx.

----------

## Carlo

 *NightDragon wrote:*   

> Ich mein, was bringt es mir wenn die META-Ebuilds die Abhängigkeiten nicht ins world-file eintragen? Wieso dann splitted ebuilds?

 

Das ist ein fundamentales Mißverständnis deinerseits. In world landen nur Ebuilds die du direkt installierst (es sei denn du nutzt --oneshot), aber niemals Abhängigkeiten.

 *NightDragon wrote:*   

> Dann sind die Meta-Pakete ja völlig sinnlos.

 

Jein. Sie sind das direkte Pendant zu den monolithischen Ebuilds - die irgendwann verschwinden werden.

 *NightDragon wrote:*   

> Ich hätte nämlich gern alle Pakete installiert und dann selektiv deinstalliert. Nicht anders rum...

 

Und so funktioniert Portage eben nicht.

 *NightDragon wrote:*   

> ...] dass die Abhängigkeiten speziell bei diesen Metas nicht im World-File stehen, wusste ich nícht

 

Nochmals: Das betrifft nicht speziell die Meta-Ebuilds. Abhängigkeiten landen niemals in world, außer du sorgst dafür. Andernfalls würde --depclean gar nicht funktionieren.

@UTGamer: Firefox 1.5 ist hart maskiert, weil die Version Sicherheitslücken hat. D.h. sofern du sie nicht lokal demaskierst, brauchst du dich über das Verhalten von Portage nicht zu wundern.

----------

## UTgamer

 *Carlo wrote:*   

> @UTGamer: Firefox 1.5 ist hart maskiert, weil die Version Sicherheitslücken hat. D.h. sofern du sie nicht lokal demaskierst, brauchst du dich über das Verhalten von Portage nicht zu wundern.

 

Thx Carlos für Notiz.

Ja habe ich mitbekommen, wie ich sie demaskiere ist mir mitlerweile während der Diskusionen wieder eingefallen.

Ja er hat Sicherheitslücken, Mozilla hat auch irgendwo angekündigt gehabt noch ein Sicherheitsupdate auf 1.5.0.13 herauszubringen. Aber ich gehe mit dem älteren FF auch garnicht surfen, ich habe ein paar mittelgroße Javascriptprogramme geschrieben und die laufen auf dem neuen FF nicht mehr so wie sie geplant waren. Ja ich schreibe in Javascript kleinere Programme für lokale Aufgaben so wie andere Perl, Python, Ruby oder sonst was nutzen.  :Wink:  Ich habe keinen Bock mit jeder Featuritisänderung von Mozilla mitzugehen, damals unter Netscape hielten Javasciptanwendungen meist länger als 4 Jahre, heute nur noch ein paar Monate, das Spiel mache ich nicht mehr länger mit. Sie laufen auf dem 1.5er und der bleibt jetzt solange ich den noch am Überleben halten kann, dann werde ich erst wieder nachlernen.

Zum surfen verwende ich Seamonkey, der läuft sowieso besser als der FF, selbst als ich noch die gleichen Versionen bei beiden hatte.  :Wink: 

Ich habe sogar noch eine ganze Desktopersatzdemo rumfliegen aus alten Netscape Zeiten die den Kioskmodus verwendet, ein ganzer Desktop aufgebaut mit Javascript   :Cool:   die läuft sogar noch leicht eingeschränkt mit dem 1.5er, auf dem neuen aber nicht mehr.   :Crying or Very sad: 

Zur Zeit stehen Javascriptarbeiten nicht auf meinem Arbeitszettel.

----------

## NightDragon

 *Carlo wrote:*   

> Das ist ein fundamentales Missverständnis deinerseits. In world landen nur Ebuilds die du direkt installierst (es sei denn du nutzt --oneshot), aber niemals Abhängigkeiten. 

 

Richtig erkannt, das hatte ich bereits ja auch schon gesagt, dass ich es falsch verstanden hatte  :Wink: 

 *Carlo wrote:*   

> Jein. Sie sind das direkte Pendant zu den monolithischen Ebuilds - die irgendwann verschwinden werden. 

 

Okay, also geht es wie bei Xorg nicht darum "it's about choice" sondern nur darum, dass man beim Updaten weniger Aufwand hat.

 *Carlo wrote:*   

> Nochmals: Das betrifft nicht speziell die Meta-Ebuilds. Abhängigkeiten landen niemals in world, außer du sorgst dafür. Andernfalls würde --depclean gar nicht funktionieren. 

 

Das hast Du falsch verstanden. Mir war klar, dass es nicht speziell diese Ebuilds betrifft. es wäre nur angenehm gewesen, wenn es speziell bei diesen Ebuilds anderst gewesen wäre wie es ist.

Und ja ich weiß, es ist nicht so, keine Wiederholungen *lach*.

----------

## SvenFischer

Leider finde ich in dem emerge Handbuch nichts über das `qlist -IC`. Würde mir das bitte jemand erklären?

----------

## Necoro

 *SvenFischer wrote:*   

> Leider finde ich in dem emerge Handbuch nichts über das `qlist -IC`. Würde mir das bitte jemand erklären?

 

man q und man qlist

btw: Ich würde dafür plädieren, im Forum anstatt der Backticks (`command`) die besser lesbare notation ($(command)) zu benutzen  :Smile: . Für jmd der sie kennt, sind sie zwar kein Problem, aber manche verwechseln sie mit einfachen Anführungszeichen  :Smile: 

----------

## Mr. Anderson

Ich hab mal wieder etwas, was in dieselbe Kerbe schlägt:

```
# emerge world -uDNpv --with-bdeps y

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

Calculating world dependencies... done!

Total: 0 packages, Size of downloads: 0 kB
```

```
emerge -epv world | grep " N "

[ebuild  N    ] app-i18n/man-pages-de-0.5  0 kB
```

Was könnte die Ursache sein?

----------

