# 1000 Gründe warum emerge -U world schlecht ist

## amne

Da sich die Verwendung von emerge -U (--upgradeonly) hartnäckig hält, eröffne ich hiermit den ultimativen Aufklärungsthread, inspiriert von diesem englischen Thread.

Warum sollte man emerge -U nicht mehr verwenden?

- Keine Downgrades, auch nicht falls diese aus Sicherheits- oder Stabilitätsgründen nötig wären.

- Die Installation von Paketen mittels ACCEPT_KEYWORDS="~x86" emerge Paketname und anschliessendem Update mittels emerge -UDv world soll schlimme Folgen haben (Ich habe das nicht ausprobiert und glaube es einfach mal so).

- Mir reichen diese zwei Gründe aus, siehe im oben genannten Thread, weitere Erkenntnisse dürfen gerne gepostet werden.  :Wink: 

Wie gehts richtig?

 :Arrow:  http://www.gentoo.de/main/de/portage-2.0.50.xml

Durch die Verwendung von /etc/portage/package.* erhält man ausgefeilte Kontrolle über die zu installierenden Pakete, eine Installation mittels ACCEPT_KEYWORDS="~x86" emerge Paketname ist obsolet, ebenso der Parameter -U.

----------

## Moorenkopf

Also ich sag' einfach mal: Ohne -U geht's bei mir nicht, weil meine nvidia-treiber dann herabgesetzt werden und dann nichts mehr funktioniert.

Ich gucke vor einem Update also immer, ob Downgrades emfpohlen werden und führe die dann per Hand aus.

Wäre gut, wenn man -U teilweise anwenden könnte.

greetz Stefan

----------

## Carlo

 *Moorenkopf wrote:*   

> Also ich sag' einfach mal: Ohne -U geht's bei mir nicht, weil meine nvidia-treiber dann herabgesetzt werden und dann nichts mehr funktioniert.

 

Also ich sag' einfach mal: Du bist zu faul zu lesen. Fang einfach bei

 *Quote:*   

> Wie gehts richtig?

 

nochmal an!

----------

## yeoman

Yep, dieses neue Portage-Feature ist wirklich prima.  :Very Happy: 

Leider gab es bei mir anfangs ein paar Probleme, da mein System durch vorherige exzessive Anwendung von ACCET_KEYWORDS und emerge -U ziemlich zugemüllt war. Mittels qpkg und ein wenig Handarbeit bekommt man es aber leicht bereinigt und seither ..... wow!

----------

## icefox13

Hatte mein System in den ersten Monaten auch mit accept_keywords laufen und hab dann nach und nach die package.mask erweitert, so dass nun ein "emerge -uD world" möglich ist. Anfangs scheinbar umständlicher (Editieren der Datei), aber im Nachhinein sehr praktisch, weil man immer eine Liste der ~x86-Pakete hat.  :Smile: 

----------

## Marlo

hi,

warum sollte man diesen Thread nicht um die Fragestellung erweitern, was man mit gentoo alles  n_i_c_h_t  machen sollte?

zB.  

```
emerge -euD world
```

----------

## Kraymer

 *amne wrote:*   

> Durch die Verwendung von /etc/portage/package.* erhält man ausgefeilte Kontrolle über die zu installierenden Pakete, 
> 
> eine Installation mittels ACCEPT_KEYWORDS="~x86" emerge Paketname ist obsolet, ebenso der Parameter -U.

 

Ich dachte, es gibt zwei Arten der Maskierung von Paketen, und nicht alles ließe sich mit packet.{mask|umask} 'freischalten'. 

Paramter -U benutz ich nicht, weil ich es nicht praktisch genug finde; daß es ernsthafte Konsequenzen haben soll, hatte ich noch nicht mitgekriegt. Momentan fahr ich mit portage-overlay recht gut.

Eingreifen in die packes.umask war bisher nur nötig, um Möglichkeiten für kde-3.3.0_alpha1 zu bekommen.

Lieg ich da ungefähr richtig? Bitte kein RTFM   :Embarassed: 

Sebastian  :Smile: 

----------

## Carlo

smash032: Es gibt auch weiterhin zwei Arten der Maskierung. ~arch (zum Testen) und via Profil (hart maskiert, bekannte, evtl. gravierende Probleme), was eben mit package.{mask|unmask}¹ übergangen werden kann und eben u.a. auf die aktuelle KDE Beta zutrifft.

Was man auch nicht machen sollte: emerge /path/to/beispiel-x.y.z.ebuild

[1] man portage

----------

## Earthwings

 *smash032 wrote:*   

>  *amne wrote:*   Durch die Verwendung von /etc/portage/package.* erhält man ausgefeilte Kontrolle über die zu installierenden Pakete, 
> 
> eine Installation mittels ACCEPT_KEYWORDS="~x86" emerge Paketname ist obsolet, ebenso der Parameter -U. 
> 
> Ich dachte, es gibt zwei Arten der Maskierung von Paketen, und nicht alles ließe sich mit packet.{mask|umask} 'freischalten'. 
> ...

 

Richtig. Aber wenn Du noch package.keywords ergänzt, kannst Du für jedes beliebige ebuild in jeder beliebigen Version die gewünschten Keywords setzen, sprich alles maskieren oder freischalten ganz nach Belieben.

 *Quote:*   

> 
> 
> Paramter -U benutz ich nicht, weil ich es nicht praktisch genug finde; daß es ernsthafte Konsequenzen haben soll, hatte ich noch nicht mitgekriegt.
> 
> 

 

Die zwei Gründe, -U nicht zu benutzen, sind

a) nicht durchgeführte downgrades, obwohl nötig, siehe amne's post (das sind übrigens die schlimmen Konsequenzen) sowie

b) Im Gegensatz zum Namen --upgradeonly gibts manchmal trotzdem downgrades - nicht aber, wenn die aus Sicherheits/Stabilitätsgründen nötig sind, sondern wenn -U mit den SLOTs durcheinanderkommt. Details auch hier.

 *Quote:*   

> 
> 
> Momentan fahr ich mit portage-overlay recht gut.
> 
> 

 

Das PORTDIR_OVERLAY braucht man nicht, um die /etc/portage Features zu nutzen.

----------

## Kraymer

@carlo: jo, danke, so hab ich's mir gedacht. 'man portage' kannte ich noch gar nicht, aber das werd ich morgen bei klarem kopf mal nachholen!

 *Earthwings wrote:*   

> Richtig. Aber wenn Du noch package.keywords ergänzt, kannst Du für jedes beliebige ebuild in jeder beliebigen Version die gewünschten Keywords setzen, sprich alles maskieren oder freischalten ganz nach Belieben.

 

Aha! Besten dank, das werd ich demnächst direkt mal probieren! Wie konnte mir das nur entgehen ?!

 *Quote:*   

> Das PORTDIR_OVERLAY braucht man nicht, um die /etc/portage Features zu nutzen.

 

Mir ware zuerst nicht ganz klar, wie Du das meinst, aber jetzt meine ich, begriffen zu haben. Besten dank euch beiden!

----------

## Carlo

Ich muß mich korrigieren. Mittels package.unmask lassen sich Ebuilds demaskieren, die in /usr/portage/profiles/package.mask maskiert sind. Via Profil (/etc/make.profile/packages) maskierte Ebuilds lassen sich so nicht dauerhaft demaskieren, da /etc/make.profile ein Symlink zurm jeweligen Profil ist und mit jedem emerge sync wieder überschrieben wird.

Die Portage man-page ist, diesen Punkt betreffend, momentan schlicht falsch, jegliche ausgearbeitete Dokumentation nicht vorhanden, lediglich im Header von /etc/make.profile/packages ist die Information zu finden.

----------

## Throx

ähm in der Gefahr, dass ihr mich auslacht ^^

/etc/portage/package.unmask , damit könnte ich z.B. dauerhaft die aktuellesten ATI-Treiber freischalten?  :Smile: 

achja, Hallo bin neu im Board ^^

----------

## sirro

 *Throx wrote:*   

> /etc/portage/package.unmask , damit könnte ich z.B. dauerhaft die aktuellesten ATI-Treiber freischalten? 

 

Nein, die würdest du mit einem Eintrag in die /etc/portage/package.keywords freischalten:

```
media-video/ati-drivers ~x86
```

Die neusten ATI-Treiber sind nicht "hart maskiert" (heißt in der globalen package.mask) sondern nur mit einem Keyword versehen.

----------

## Throx

ah danke, das werd ich dann mal sofort machen  :Smile: 

----------

## Lenz

Mit der neuen Portageversion hat sich -U nun wohl ohnehin erledigt.  :Wink: 

----------

